UNIVERSIDADE LUTERANA DO BRASILCURSO 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

Canoas, novembro de 2005.

2

Universidade Luterana do Brasil – ULBRACurso 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 PetryProf. 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 CanoasAv. 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

LISTA DE FIGURAS...............................................................................................................6

LISTA DE TABELAS..............................................................................................................7

LISTA DE QUADROS.............................................................................................................8

LISTA DE ABREVIATURAS E SIGLAS..............................................................................9

RESUMO.................................................................................................................................10

ABSTRACT.............................................................................................................................11

1 INTRODUÇÃO..................................................................................................................12

2 ELEVADORES..................................................................................................................132.1 SURGIMENTO DO ELEVADOR.......................................................................................132.2 DESENVOLVIMENTO TECNOLÓGICO E TENDÊNCIAS....................................................142.3 ENGENHARIA DE ELEVAÇÃO........................................................................................14

2.3.1 Estudo de Tráfego................................................................................................152.3.2 Cálculo de Tráfego...............................................................................................16

2.4 NECESSIDADES DA ÁREA DE PESQUISA E DESENVOLVIMENTO....................................17

3 SIMULAÇÃO.....................................................................................................................183.1 CONCEITO....................................................................................................................183.2 METODOLOGIAS..........................................................................................................193.3 FERRAMENTAS EXISTENTES.........................................................................................19

4 PROJETO DA FERRAMENTA.......................................................................................224.1 MOTIVAÇÃO................................................................................................................224.2 OBJETIVOS...................................................................................................................234.3 METODOLOGIA ADOTADA...........................................................................................24

4.3.1 Orientação a Objetos............................................................................................244.3.2 Processo Unificado..............................................................................................244.3.3 UML ....................................................................................................................25

4.4 RECURSOS EMPREGADOS.............................................................................................254.4.1 Modelagem..........................................................................................................254.4.2 Implementação.....................................................................................................26

5 DESENVOLVIMENTO DA FERRAMENTA................................................................275.1 LEVANTAMENTO DOS CASOS DE USO..........................................................................275.2 PACOTES BÁSICOS.......................................................................................................295.3 PACOTES ESPECÍFICOS DO SISTEMA.............................................................................31

5.3.1 Pacote Prédio.......................................................................................................32

5

5.3.2 Pacote Pessoa.......................................................................................................335.3.2.1 População Programada...............................................................................335.3.2.2 Geradores de População.............................................................................345.3.2.3 Usos de um Prédio......................................................................................36

5.3.3 Pacote Elevador...................................................................................................385.3.3.1 Visão Geral das Classes do Pacote.............................................................385.3.3.2 Lógica de Atendimento..............................................................................40

5.3.4 Pacote Simulação.................................................................................................415.4 EXECUÇÃO DA SIMULAÇÃO.........................................................................................44

6 UTILIZAÇÃO DO PROTÓTIPO....................................................................................526.1 EXEMPLO DE SIMULAÇÃO............................................................................................526.2 COMPARAÇÃO COM CÁLCULO DE TRÁFEGO................................................................58

6.2.1 Cálculo 1..............................................................................................................586.2.2 Cálculo 2..............................................................................................................60

7 CONCLUSÃO....................................................................................................................62

REFERÊNCIAS........................................................................................................................64

LISTA DE FIGURAS

Figura 1 – Simulação de um processo de manufatura com o programa Arena........................20Figura 2 – Modelo de condicionador de ar com o programa Vensim.......................................21Figura 3 – Casos de uso do sistema..........................................................................................27Figura 4 – Dependência entre os casos de uso..........................................................................29Figura 5 – Divisão básica das classes em pacotes.....................................................................31Figura 6 – Pacotes para agrupar três grupos bem distintos de entidades..................................32Figura 7 – Visão geral das classes do pacote Prédio.................................................................32Figura 8 – Programação da população de passageiros..............................................................33Figura 9 – Relação entre geradores de população e população programada............................35Figura 10 – Classes que representam relação entre uso e população estimada........................37Figura 11 – Definição da interface IUso...................................................................................37Figura 12 – Operação da classe UsosPredio que obtem o total de pessoas..............................38Figura 13 – Visão geral das classes do pacote Elevador...........................................................39Figura 14 – Estrutura do estudo no simulador..........................................................................42Figura 15 – Classes Cenário e Comparativo.............................................................................43Figura 16 – Classe simulação e seus relacionamentos..............................................................43Figura 17 – Execução da simulação no objeto Simulação........................................................45Figura 18 – Execução da simulação no objeto SistemaElevadores..........................................46Figura 19 – Execução da simulação no objeto Elevadores.......................................................46Figura 20 – Estados do objeto Cabine......................................................................................47Figura 21 – Estados do objeto PortaCabine..............................................................................48Figura 22 – Execução da simulação no objeto População........................................................49Figura 23 – Estados do objeto Pessoa.......................................................................................50Figura 24 – Edição da estrutura física de um prédio.................................................................53Figura 25 – Estimativa da população baseada nos usos do prédio...........................................54Figura 26 – Distribuição das pessoas em momentos de chegada..............................................55Figura 27 – Edição do sistema de elevadores...........................................................................56Figura 28 – Cenário com simulação em execução....................................................................57Figura 29 – Comparativo exemplo............................................................................................58Figura 27 – Prédio configurado de acordo com o cálculo de tráfego.......................................59Figura 28 – Resultado da simulação do cálculo 1.....................................................................60Figura 29 – Fim da execução da simulação do cálculo 2..........................................................61Figura 30 – Resultado da simulação do cálculo 2.....................................................................61

LISTA DE TABELAS

Tabela 1 – Programação de Origens.........................................................................................34Tabela 2 – Programação de Destinos........................................................................................35Tabela 3 – Distribuição de pessoas no tempo...........................................................................36Tabela 4 – Distribuição de pessoas nos pavimentos num dado instante...................................36

LISTA DE QUADROS

Quadro 1 – Detalhamento dos casos de uso do sistema............................................................28

LISTA DE ABREVIATURAS E SIGLAS

ABNT Associação Brasileira de Normas TécnicasCAD Computer Aided DesignCASE Computer Aided Software EngineeringNBR Norma BrasileiraOMG Object Management GroupUML Unified Modeling LanguageVB 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.

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.

17

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;

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.

21

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.

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.

26

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.

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:

Quadro 1 – Detalhamento dos casos de uso do sistemaCaso de Uso DescriçãoConstruir 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.

28

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

29

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.

30

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.

31

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

32

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,

33

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 OrigensPav. 1 Pav. 2 Pav. 3 Pav. 4 Pav. 5 Pav. 6

15/10/2005 08:00:00 6 5 5 4 5 615/10/2005 08:01:00 0 4 4 5 2 415/10/2005 08:02:00 2 4 0 5 4 415/10/2005 08:03:00 3 3 2 6 2 1

34

Tabela 2 – Programação de DestinosPav. 1 Pav. 2 Pav. 3 Pav. 4 Pav. 5 Pav. 6

15/10/2005 08:00:00 25 2 0 2 1 015/10/2005 08:01:00 4 7 8 1 2 415/10/2005 08:02:00 15 1 0 0 2 415/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:

35

Tabela 3 – Distribuição de pessoas no tempoTempo Pessoas (%)15/10/2005 08:00:00 5515/10/2005 08:01:00 3015/10/2005 08:02:00 1515/10/2005 08:03:00 0

Tabela 4 – Distribuição de pessoas nos pavimentos num dado instantePavimento Origem (%) Destino (%)1 100 02 0 203 0 204 0 205 0 206 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.

36

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 clsIUsoPredioEnd 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.

37

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

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

Return ValorEnd 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.

38

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.

39

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

40

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.

41

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.

42

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

43

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.

44

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.

45

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

46

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

47

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.

48

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.

49

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

50

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.

51

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.

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.

53

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.

54

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.

55

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.

56

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.

57

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.

58

O prédio, a população e o sistema de elevadores foram construídos no simulador de acordo como descrito no cálculo. Diversas simulações foram feitas para tentar amenizar fatores aleatórios de geração de população através do gerador relativo. Os resultados ficaram entre 29 e 31 pessoas, sendo satisfatório para validar o comportamento do simulador. Nas Figuras 30 e 31 são mostrados a configuração do prédio e o resultado de uma das simulações executadas.

Figura 30 – Prédio configurado de acordo com o cálculo de tráfego

59

Figura 31 – Resultado da simulação do cálculo 1

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.

60

Figura 32 – Fim da execução da simulação do cálculo 2

Figura 33 – Resultado da simulação do cálculo 2

61

7 CONCLUSÃO

Com a realização deste trabalho, foi evidenciado que, com a apropriada tecnologia, como a orientação a objetos, e com a adequada técnica de modelagem, problemas do mundo real podem ser trazidos para um mundo simulado para fim de estudo e experimentação em busca de uma solução ou melhoria em soluções existentes com o auxílio do computador. Isso somado ao fato da grande difusão de informática, principalmente através da constante diminuição do custo de equipamentos com cada vez mais poder de processamento, torna a simulação por computador uma alternativa interessante para solução de problemas e que deve ser considerada.

Uma importante diretriz que o desenvolvedor deve manter em mente para a construção de aplicativos de simulação é não “contaminar” o modelo computacional que está sendo criado com características do mundo real que não são pertinentes à solução do problema, trazendo para a simulação objetos e características que não influenciam os resultados, numa ânsia de “simular tudo”. No início deste trabalho, houve este desvio, mas o rumo correto foi devidamente tomado de volta através da adequada orientação.

Outro aspecto relevante é que o modelo produzido deve ser constantemente refinado, mesmo depois do aplicativo estar desenvolvido, para que a simulação seja e se mantenha fiel à realidade, tendo assim realmente valor para o usuário. Para isso, deve-ser trabalhar e manter constante contato com os especialistas do domínio para o qual a ferramenta está sendo ou foi desenvolvida. Desse modo, discrepâncias de resultados e a desatualização do modelo podem ser evitados.

Este trabalho realizou simulação para um domínio de problema que envolve pessoas, hardware, software e mecânica. Isto leva a reflexão sobre quais outros domínios de problemas também podem ser simulados e que se tornariam ferramentas interessantes para auxiliar o desenvolvimento tecnológico e científico.

Toda a pesquisa feita e conhecimentos obtidos, além de servirem de base para o trabalho, ampliaram os horizontes sobre o problema e levantaram mais questões, que podem servir de partida para trabalhos futuros, sendo alguns sugeridos abaixo:

Melhoria na Apresentação da Simulação – uma interface gráfica mais elaborada poderia ser implementada para apresentar o andamento da simulação, talvez até usando algum motor de imagens tridimensionais como DirectX ou OpenGL.

Editor de Lógica de Atendimento – como o programa está implementado atualmente, uma nova lógica de atendimento ou a edição de uma existente só pode ser feita através de alteração do código-fonte e recompilação do programa, o que além ser inflexível, requer certos conhecimentos técnicos de desenvolvimento de

software. Uma alternativa seria criar um editor de lógicas de atendimento. No pacote Elevador seria acrescentada uma nova classe que implementaria a interface ILogicaAtendimento (como é atualmente para se acrescentar uma nova lógica de atendimento no sistema) sendo que esta classe tem o seu comportamento programável pelo usuário. Dois caminhos parecem promissores: um seria a leitura de um arquivo de script em alguma linguagem, talvez Javascript, pela nova classe; o outro seria a edição visual da lógica pelo usuário produzindo algum tipo de diagrama que depois seria executado pela nova classe. Uma outra arquitetura bem mais sofisticada para essa solução seria fazer uma nova classe lógica de atendimento que abra uma porta de TCP/IP e permita a conexão de outro aplicativo que assume o papel de lógica de atendimento. Para isto seria necessária a definição de um protocolo. Tal arquitetura permite que diferentes editores de lógica de atendimento sejam implementados sem alteração do simulador.

Criação de Atributos para Pessoa – uma ampliação do sistema seria permitir que o usuário criasse livremente atributos para a pessoa e configurando o valor desses atributos junto com a população. Esses atributos poderiam ser levados em consideração pela lógica de atendimento no seu processamento de chamadas. Por exemplo, o usuário poderia criar na pessoa um atributo booleano chamado deficiente. Isto indica para a lógica de atendimento que aquela pessoa deve ser atendida de forma especial. Esta melhoria só teria sentido se a editor de lógica de atendimento fosse implementado.

Alimentação com Dados Reais – poderia ser interessante se um dispositivo de hardware no prédio conseguisse coletar dados sobre o comportamento da população de passageiros que ele atende de tal forma que esses dados possam ser importados pelo aplicativo de simulação para gerar uma população de passageiros de comportamento semelhante, sendo assim um retrato mais fiel da realidade.

63

REFERÊNCIAS

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. Rio de Janeiro: Campus, 2000. 472p.

EIWA SYSTEM MANAGEMENT. UML Modeling Tool – Jude. 2005. Disponível em: <http://www.esm.jp/jude-web/product/function.html>. Acesso em: 2 nov. 2005.

LARMAN, Craig. Utilizando UML e Padrões. 2ª ed. Porto Alegre: Bookman, 2004. 607p.

PERIN FILHO, Clovis. Introdução à Simulação de Sistemas. Campinas: Unicamp, 1995. 163 p.

PRADO, Darci. Teoria das Filas e da Simulação. Belo Horizonte: INDG, 2004. 126 p.

ROCKWELL AUTOMATION. Arena Product Overview. Disponível em: <http://www.arenasimulation.com/products/default.asp>. Acesso em: 15 abr. 2005.

ROMAN, Steve; PETRUSHA, Ron; LOMAX, Paul. Linguagem VB.Net. Rio de Janeiro: Campus, 2002. 699 p.

SGRILLO, Ricardo. Dinâmica de Sistemas. 2003. Disponível em: <http://paginas.terra.com.br/informatica/sgrillo/sysdyn/>. Acesso em: 26 out. 2005.

STRAKOSCH, George R. The Vertical Transportation Handbook. 3ª ed. Nova Iorque: John Wiley and Sons, 1998. 564p.

VENTANA SYSTEMS. Vensim Software. Disponível em: <http://www.vensim.com/software.html>. Acesso em: 15 abr. 2005.