Protótipo de Simulador de Elevadores

5,569
-1

Published on

Baixe mais arquivos em http://pastadomau.wikidot.com.
Este trabalho 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. A simulação permite a
avaliação das diferentes alternativas de projeto de elevadores. O protótipo foi desenvolvido em Visual Basic.net.
Este foi o meu trabalho de conclusão de curso (TCC).

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,569
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
87
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Protótipo de Simulador de Elevadores

  1. 1. UNIVERSIDADE LUTERANA DO BRASIL CURSO DE SISTEMAS DE INFORMAÇÃO CÂMPUS CANOAS PROTÓTIPO DE SIMULADOR DE ELEVADORES Mauricio Volkweis Astiazara Monografia desenvolvida durante a disciplina Trabalho de Conclusão de Curso em Sistemas de Informação II e apresentada ao Curso de Sistemas de Informação da Universidade Luterana do Brasil, câmpus Canoas, como pré-requisito para a obtenção do título de Bacharel em Sistemas de Informação. Orientador: Prof. Roland Teodorowitsch
  2. 2. 2 Canoas, novembro de 2005.Universidade Luterana do Brasil – ULBRACurso de Sistemas de Informação – Câmpus CanoasReitor: Pastor Ruben Eugen BeckerVice-Reitor: Eng. Leandro Eugênio BeckerDiretor da Faculdade de Informática: Prof. Gilberto Fernandes MarchioroCoordenador de Curso (Câmpus Canoas): Prof. Gilberto Fernandes MarchioroCoordenador das Disciplinas de Trabalho de Conclusão de Curso (Câmpus Canoas): Profª. Denise Salvadori VirtiBanca Avaliadora composta por: Data da defesa: 06/12/2005. Prof. Roland Teodorowitsch (Orientador) Prof. Adriano Petry Prof. Alexandre Berg CIP – Catalogação na Publicação Astiazara, Mauricio Protótipo de Simulador de Elevadores / Mauricio Volkweis Astiazara; orientado por Roland Teodorowitsch. – Canoas: 2005. 64 p.: il. Trabalho de Conclusão de Curso (Graduação em Sistemas de Informação). Universidade Luterana do Brasil, 2005. 1. Simulação. 2. Elevador. 3. Orientação a Objetos. I. Teodorowitsch, Roland. II. Título.Endereço:Universidade Luterana do Brasil – Câmpus CanoasAv. Farroupilha, n° 8.001 - Bairro São LuísCEP 92420-280 Canoas-RS – Brasil
  3. 3. AGRADECIMENTOS Agradeço à empresa Wise Engenharia Eletrônica e Informática pela contribuição epelos recursos cedidos, sem os quais este trabalho não seria realizado.
  4. 4. SUMÁRIO1 INTRODUÇÃO....................................................................................................................112 ELEVADORES....................................................................................................................123 SIMULAÇÃO.......................................................................................................................174 PROJETO DA FERRAMENTA........................................................................................215 DESENVOLVIMENTO DA FERRAMENTA..................................................................266 UTILIZAÇÃO DO PROTÓTIPO......................................................................................527 CONCLUSÃO......................................................................................................................62
  5. 5. LISTA DE FIGURAS
  6. 6. LISTA DE TABELAS
  7. 7. LISTA DE QUADROS
  8. 8. LISTA DE ABREVIATURAS E SIGLASABNT Associação Brasileira de Normas TécnicasCAD Computer Aided DesignCASE Computer Aided Software EngineeringNBR Norma BrasileiraOMG Object Management GroupUML Unified Modeling LanguageVB Visual Basic
  9. 9. RESUMO Este artigo descreve o projeto e o desenvolvimento de uma ferramenta para asimulaçã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á aavaliação de diferentes projetos de elevadores. Palavras-chaves: Simulação; Elevador; Orientação a Objetos.
  10. 10. ABSTRACTTitle: “Prototype of Elevators Simulator” This paper describes the design and the development of a tool for simulation ofelevator systems. The objective of that tool is to provide assistance to the elevationtechnology researcher. The simulator will allow the evaluation of different elevator projects. Key-words: Simulation; Elevator; Object Technology.
  11. 11. 1 INTRODUÇÃO Na indústria de elevadores, a área de venda e dimensionamento tem meios para avaliaro 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 tabelasque descrevem o desempenho dos atuais produtos de elevação. A área de pesquisa edesenvolvimento também tem necessidade de realizar avaliações e experimentos, porém nãopode utilizar os mesmos cálculos da área de venda e dimensionamento porque estes sãototalmente baseados em tecnologias existentes, e não dão margem a variações para teste denovas propostas e alternativas de projeto. Para auxiliar a área de pesquisa e desenvolvimento, é proposta uma ferramenta não decálculo, mas sim de simulação de elevadores. Esta ferramenta incorpora nos seus objetossimulados o mesmo comportamento dos objetos reais e ainda permite um maior grau deconfiguração e flexibilidade. O produto desenvolvido é um protótipo funcional que deveprovar 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 queestá sendo abordado. Em seguida, uma conceituação sobre simulação é feita, bem comometodologias para simulação e ferramentas existentes no mercado. É definida uma propostade ferramenta no capítulo seguinte. Toda a modelagem e desenvolvimento da ferramenta sãodescritos no Capítulo 5. O capítulo seguinte já explora o protótipo produzido em ação. Aofinal são relatadas as conclusões obtidas com o trabalho e as referências utilizadas.
  12. 12. 2 ELEVADORES Para um melhor entendimento sobre elevadores, é feito um breve histórico de comosurgiu este meio de transporte, como se deu o seu desenvolvimento tecnológico e tendênciasde tecnologia para o futuro. Passa-se então a uma introdução à disciplina de engenharia deelevaçã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 emgrupo sempre favoreceu a humanidade desde os tempos mais remotos, por exemplo, caçandoem conjunto. Desde o nascimento das primeiras cidades, o que se viu foi uma urbanizaçãocrescente; as pessoas deixando o campo e indo morar e trabalhar na cidade. Esse fenômeno de agrupamento acarreta uma maior quantidade de pessoas em ummesmo espaço, o que requer melhor aproveitamento da área disponível. Edificações de maisde um piso existem desde a antiguidade, mas vieram atender especialmente bem ànecessidade sempre crescente de mais pessoas no mesmo lugar, manifestadas atualmentecomo 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 comtransporte vertical de pessoas e materiais. No começo, eram usados meios rudimentares, comoescadas, rampas, cestas e plataformas erguidas por tração animal ou até mesmo humana. Como aprimoramento, surgiram os dispositivos baseados em trilhos verticais ou guias. Estesdispositivos evoluíram para a forma de elevador no início de 1800. Neste período, a principalutilização destes elevadores era o transporte de materiais e, ocasionalmente, de pessoas. Aindanão havia mecanismos de segurança e os resultados eram desastrosos quando o cabo desustentação se rompia (STRAKOSCH, 1998). Em 1853, Elisha Graves Otis inventou o mecanismo de segurança de elevadores. Estemecanismo foi projetado para prevenir a queda livre da plataforma de elevação caso o cabo serompa. Devido a essa invenção, o uso de elevadores para transporte de pessoas começou a teraceitaçã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 umtransporte projetado para mover pessoas ou materiais verticalmente. Este transporte deveincluir um mecanismo de segurança para evitar a queda em caso de falha.
  13. 13. 132.2 DESENVOLVIMENTO TECNOLÓGICO E TENDÊNCIAS Nos primórdios da indústria de elevadores, a maior evolução ocorreu na área daengenharia mecânica. A mecânica era usada para realizar o trabalho de erguer a cargatransportada. 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-semuito 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. Istopermitiu o aparecimento do primeiro elevador de botão. A aplicação de controladoreselétricos estabilizou o tempo de viagem do elevador, uma vez que a velocidade não maisdependia de fatores como a pressão da água (para elevadores hidráulicos) e característicasmecânicas (para elevadores a tração). Outra melhoria que a eletricidade trouxe posteriormentefoi 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 umatecnologia empregada no transporte vertical. Inicialmente, microcontroladores permitiram ummelhor gerenciamento dos motores, aumentando a velocidade e, conseqüentemente,diminuindo o tempo de viagem. Uma melhor suavização da aceleração e desaceleraçãotambé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, maisoperações do elevador tornaram-se eletrônicas, possibilitando a aumento no conforto eagregaçã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 quejá se observa há algum tempo, e que tende a ser o caminho, não é uma substituição damicroeletrônica pela informática, mas sim uma integração e complementação. Essa integraçãodá-se, por exemplo, através de sistemas de elevadores se comunicando com sistemas deinformaçã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 ossistemas de elevadores enviando configurações e comandos, servindo de interface de maisalto nível entre o Homem e o sistema de elevador. Essas aplicações já podem ser vistas noschamados 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 deinformaçã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 aotoque 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, realizandooperações críticas como lógicas de atendimento de chamadas. Isso facilitará ainda mais aintegração com os sistemas de informação, podendo talvez o sistema de elevadores serconectado diretamente à rede de computadores local, e até mesmo à rede mundial decomputadores, para fornecer e consultar dados estatísticos sobre o tráfego de pessoas nopré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 aumentodo tamanho e altura dos prédios naquela época, questões como quantidade, tamanho elocalização dos elevadores começaram a ser levantadas (STRAKOSCH, 1998). Um
  14. 14. 14pensamento típico e errado da época era que “se um prédio possui um sistema de elevadoresque atende às suas necessidades de tráfego, para um prédio com o dobro do tamanho bastadobrar a quantidade de elevadores”. Evidenciou-se que esta lógica não é verdadeira e anecessidade 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ívelpara satisfazer a demanda de tráfego em prédios de múltiplos andares. Ela envolve umcuidadoso estudo da população total esperada para ocupar os pisos superiores, um estudosobre os padrões de tráfego dessa população, o apropriado cálculo do desempenho do sistemade 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 termosde qualidade de transporte e qualidade de serviço. Qualidade de transporte é a capacidade dosistema de elevadores transportar uma quantidade de passageiros em 5 minutos. Quanto maiora 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ísregulamenta exigências mínimas de qualidade de transporte e qualidade de serviço para cadatipo de prédio (comercial, residencial, etc.). No Brasil, essas exigências estão na normabrasileira (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 arespeito da população do prédio. Isto inclui levantamento de informações sobre como aspessoas irão chegar, ocupar e se mover no prédio. Os fatores básicos de estudo incluem onúmero de ocupantes e visitantes, sua distribuição pelos pavimentos, os tempos e as taxas dechegada e partida. Tais informações podem ser determinadas, dependendo se o prédio emquestão é existente ou ainda está em construção, por observações, discussões comadministradores e proprietários e por pesquisa das necessidades de uso dos ocupantes (oufuturos ocupantes) e da população. Este estudo sobre a população visa o descobrimento do período crítico de tráfego. Operíodo crítico de tráfego é o período de 5 minutos em que o sistema de elevadores é maisrequisitado. O tipo, direção e intensidade do tráfego durante este período determinam aquantidade de serviço de elevação necessária para o prédio. Se os elevadores servem bem aotráfego durante o período crítico, eles são capazes de satisfazer ao tráfego durante todos osoutros períodos. Por exemplo, para um prédio de escritórios, o período crítico de tráfego podeser de manhã, pouco antes do horário de início da jornada de trabalho, com tráfegopredominantemente para cima, pois as pessoas estão tentando chegar em suas mesas paracomeçar a trabalhar. Em suma, um dos objetivos do estudo de tráfego é a obtenção daquantidade de passageiros que o sistema de elevadores precisa transportar em 5 minutos, ouseja, a qualidade de transporte necessária, bem como a direção predominante do tráfego: paracima, para baixo ou misto.
  15. 15. 15 Outro objetivo do estudo de tráfego é determinar a qualidade de serviço necessáriapara o prédio. Estudos e observações realizados ao longo dos anos têm mostrado que ospassageiros se tornam impacientes depois de aguardar 30 segundos pelo elevador em prédioscomerciais e 60 segundos em prédios residenciais (STRAKOSCH, 1998). Logo esses sãobons parâmetros de qualidade de serviço. Porém, outros valores menores podem ser exigidosdevido 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 noestudo de tráfego, servem de entrada para o cálculo de tráfego. O cálculo de tráfego consisteno uso de um modelo matemático (fórmulas e tabelas) para auxiliar na obtenção da apropriadaquantidade, velocidade e tamanho dos elevadores. As fórmulas e tabelas utilizadas no cálculo de tráfego são o resumo do desempenho datecnologia da elevação existente (fatores de tempo e carga, principalmente) e docomportamento da população de passageiros diante desta tecnologia. Essas tabelas e fórmulaspermitem 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 dediversos 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 osseguintes: 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 mencionadosacima. A aplicação correta do modelo para cálculo depende não só de conhecimentomatemático, mas de conhecimento teórico sobre elevação. Por exemplo, para aumentar aqualidade 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 deespera do passageiro. O resultado do cálculo de tráfego para um prédio em construção é um argumentosólido para justificar a adoção de uma determinada solução, pois é baseado num modelomatemático, racional, fruto de anos de estudo da elevação, sendo a principal ferramenta paraencontrar o equilíbrio entre economia e qualidade.
  16. 16. 162.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 principalmentepela área de vendas de elevadores novos e modernizações de elevadores existentes. A área depesquisa e desenvolvimento de tecnologias para elevação também precisa de um modelo quereflita 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 enecessidades 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 enfoquede pesquisa e desenvolvimento de novas tecnologias de elevação, muitas necessidades não sãoatendidas. O modelo usado no estudo da elevação está apoiado nas características e limitaçõesdas tecnologias existentes e altamente consolidadas, o que diverge do objetivo de estudo dautilização de uma nova tecnologia para melhorar a vazão do tráfego. Uma nova tecnologiapode ter características bem diferentes das atualmente utilizadas, não sendo facilmenteacomodada no cálculo, como é a diminuição de um fator de tempo, por exemplo. Em certoscasos, a aplicação de novas tecnologias muda até mesmo o comportamento da população depassageiros. 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 dapopulação de passageiros foram sumarizados em um comportamento médio estatístico. Tallinearidade é útil para o cálculo através de fórmulas e tabelas, mas não deixa margem para aobservação de como o comportamento individual dos passageiros afeta de modo geral odesempenho do sistema de elevadores. O que se tem é um “aplainamento” de algo que naverdade é “irregular”. Com o atual modelo, é difícil avaliar como o comportamento da população depassageiros é afetado frente a uma nova situação, como um dispositivo de chamada comcomportamento diferenciado, ou presença ou ausência de indicadores no pavimento. Estemodelo não pode responder a muitas perguntas do tipo “se isso fosse assim, o queaconteceria?”. 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 depassageiros e sistema de elevadores) foram transformados em abstrações matemáticascontendo somente os pontos de interesse do cálculo de tráfego. Para a área de pesquisa edesenvolvimento seria necessário um trabalho semelhante: criar um modelo específico, queatenda às necessidades da área de pesquisa e desenvolvimento, a partir dos objetos do mundoreal. Uma alternativa é colocar o comportamento desses objetos dentro de um simulador aoinvés de dentro de tabelas e fórmulas.
  17. 17. 3 SIMULAÇÃO Segundo Perin Filho (1995, p. 17), existem, de modo geral, três estratégias deresolução de problemas: experimentação direta, resolução analítica e simulação. Aexperimentação direta consiste em fazer experimentos diretamente no sistema real para tentarencontrar a melhor solução por tentativa e erro. Por sua vez, a resolução analítica consiste emconstruir um modelo analítico e aplicar um método matemático para obter a melhor soluçãopara o problema. Já na simulação de sistemas, experimentos são feitos para tentar encontrar amelhor solução por tentativa e erro, como na experimentação direta, porém não no sistemareal, 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 tentacompreender 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 dodesempenho de um modelo que representa um sistema definido a partir de um problema a serresolvido. O modelo é usado como uma ferramenta de experimentação que, através detentativa e erro, permite comparar diversos cenários, cada um representando uma política deoperaçã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 destetrabalho uma vez que se refere à simulação informatizada: “Simulação é a técnica de soluçãode um problema pela análise de um modelo que descreve o comportamento do sistema usandoum computador digital”. Diferentes fatores podem levar ao uso da simulação ao invés da experimentação direta: • Tempo: o computador pode realizar rapidamente experimentos que no sistema real consomem anos; • Custo: cada experimentação no sistema real é muito dispendiosa; • Impossibilidade de experimentação direta: experimentações no sistema real não podem ser realizadas por questões de segurança (como oferecer perigo para seres humanos ou para o meio ambiente), de acesso ou ainda inexistência (o sistema está em construção ou sendo estudada a construção); • Visualização: computadores permitem uma fácil visualização dos resultados, o que é importante no processo de tomada de decisões;
  18. 18. 18 • Repetição: dificilmente experiências no sistema real podem ser repetidas para uma observação mais detalhada do seu comportamento, porém, isso é realizado de modo fácil na simulação realizada por computador.3.2 METODOLOGIAS Para implementar um sistema de simulação, basicamente três orientações sãopossíveis: • Orientado para atividades; • Orientado para eventos; • Orientado para objetos. Na programação orientada para atividades, a forma de controle do tempo de simulaçãose dá através da divisão do tempo total de simulação em intervalos menores e de mesmotamanho. A simulação é realizada em cada intervalo. Assim, o “relógio” sofre incrementosregulares e, a cada passagem de tempo, é feita uma varredura em todas as atividades dasimulação para atualização das variáveis de estado. Já a orientação para eventos normalmente utiliza-se de um relógio que é incrementadocom o valor necessário para a chegada do tempo do próximo evento de interesse dasimulação. Dessa forma, o tempo não passa de forma linear, mas sim aos saltos, passandosomente pelos momentos de valor para a simulação (eventos). Esta técnica de controle dorelógio economiza recursos computacionais. A programação de simulação orientada para objetos, de certa forma, constitui umacombinação e generalização das duas orientações anteriores. Nesta orientação, as entidades deinteresse da simulação são transformadas em objetos, incorporando além dos dadoscorrespondentes aos seus atributos os procedimentos computacionais relacionados às suasatividades. 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 adeterminadas á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 aanimação de um fluxograma até a geração de imagens de três dimensões, dependendo dadistribuição. A Figura 1 exibe a execução da simulação de um processo de manufatura noaplicativo.
  19. 19. 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 VentanaSystems. Este programa é mais genérico porque trabalha com fórmulas matemáticas, podendosimular qualquer coisa que possa ser representada por fórmulas. Ele permite criar e interligardiferentes 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 pelousuário (VENTANA SYSTEMS, 2005). Na Figura 2 apresenta-se um exemplo de uso destaferramenta 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 UniversidadeEstadual de Santa Cruz.
  20. 20. 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 aplicadosa diferentes domínios de problema. Com uma maior gama de aplicação, a quantidade depossíveis clientes aumenta. Porém essa generalidade sacrifica em certo grau a fidelidade, ariqueza e o detalhamento da simulação para um domínio específico, e, por conseqüência, ovalor da simulação em si para o usuário. Uma analogia pode ser feita com uma planilhaeletrô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 umsupermercado, 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, naanalogia, um programa de controle de estoque. Acredita-se ser este o caso do estudo da elevação com o enfoque de pesquisa edesenvolvimento de novas tecnologias: o mais valoroso para o usuário seria uma ferramentaespecializada na simulação de elevadores, que atenda aos seus objetivos específicos destedomínio.
  21. 21. 4 PROJETO DA FERRAMENTA Considerando-se a necessidade levantada nos capítulos anteriores, foi proposto odesenvolvimento de uma ferramenta de simulação para atendê-la. Nesta ferramenta, o usuárioentra com a população de passageiros (suas características, quantidade, posição, direção detrá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 depassageiros passa a interagir com o sistema de elevadores visando chegar no seu andar dedestino. No decorrer da simulação, dados sobre o desempenho da solução são coletados. Asimulação é apresentada como uma animação para o usuário, ajudando na observação docomportamento 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 foiresumido para fins de cálculo. Com um objeto simulado que apresenta o comportamentodefinido no cálculo de tráfego, que por sua vez foi baseado no mundo real, tem-se apossibilidade 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 eexperimentaçã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 ferramentasespecíficas para a sua área técnica, como programas de CAD (Computer Aided Design) paradesenho 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 umaferramenta 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 cedoou mais tarde passam a fazer parte do cotidiano das pessoas. Espera-se que com essaferramenta haja um aumento na produtividade dos estudos de pesquisa e desenvolvimento detecnologia para a elevação, o que indiretamente contribui para a vida da população em geral.
  22. 22. 22 Esta ferramenta pode não só ajudar no desenvolvimento de novas tecnologias, comotambém ajudar a justificar a aplicação de soluções já em campo, elucidando por quedeterminadas alternativas de projeto foram descartadas e a atual foi utilizada. Pode até mesmovir a ser usada como uma ferramenta didática, exemplificando conceitos e auxiliando naintroduçã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 funcionalidadesdesejadas para um produto final não serão implementadas por questão de tempo, como, porexemplo, um editor de lógicas de atendimento (mencionado anteriormente), para que opró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 eamadurecimento dessa ferramenta.
  23. 23. 234.3 METODOLOGIA ADOTADA Foi escolhida a abordagem de análise e projeto orientados a objetos devido às suasinúmeras vantagens. Para apoiar esse paradigma de desenvolvimento de sistemas, foi tomadacomo base a metodologia Processo Unificado. Esta metodologia se vale da UML (UnifiedModeling 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 umanovidade ou tendência. Atualmente, a sua aplicação está muito bem difundida e consolidadano mercado de desenvolvimento de sistemas de informação. A visão tradicional no desenvolvimento de software adotava a perspectiva de umalgoritmo. Nessa visão, o principal bloco de construção do software é o procedimento oufunção. Essa perspectiva conduz os desenvolvedores a voltarem o seu foco de atenção paraquestõ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 permitirsistemas instáveis. À medida que os requisitos se modificam (e isso certamente ocorrerá) e osistema cresce (o que também acontecerá), será difícil fazer a manutenção de sistemasconstruídos a partir do foco em algoritmos. A visão contemporânea do desenvolvimento de sistemas de informação adota umaperspectiva orientada a objetos. Nessa visão, o principal bloco de construção do sistema é oobjeto ou a classe. De forma simplificada, pode-se dizer que uma classe é especificação decomo se constituem e de como se comportam todos os objetos criados como sendopertencentes a esta classe. Um objeto contém dados (variáveis) e operações (funções). Umadas principais características de um sistema orientado a objetos é que a sua estrutura tende arefletir a estrutura de objetos de negócio do mundo real, facilitando a comunicação entreanalistas e usuários. Além disso, o desenvolvimento orientado a objetos favorece areutilizaçã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 chamadaProcesso Unificado, que fornece uma abordagem para a construção de sistemas orientados aobjetos. O Processo Unificado pode ser considerado o antecessor do RUP (Rational UnifiedProcess), o processo de desenvolvimento de software da empresa Rational; o RUP é umrefinamento do Processo Unificado (LARMAN, 2004). O termo “parcialmente” foi utilizadoporque não é pretendida uma execução exata do Processo Unificado, ele será a principal basemas também serão aplicados conceitos de outras metodologias que forem consideradasconvenientes, como, por exemplo, da metodologia Objectory. Dentre as características do Processo Unificado, está o esforço inicial em construiruma arquitetura central e coesa. Logo no começo é definida uma “espinha dorsal” daarquitetura, focalizando uma implementação ampla e rasa, estabelecendo os temas principaisdo projeto e os subsistemas com suas interfaces e responsabilidades. Outra prática do Processo Unificado é a modelar visualmente o sistema. Umaporcentagem extraordinária do cérebro humano está envolvida com o processamento visual.
  24. 24. 24Portanto, as pessoas não têm somente habilidade em empregar linguagens textuais (comoprosa ou código), mas também linguagens visuais espaço-orientadas, icônicas, diagramáticascomo UML, porque isto explora as forças naturais do cérebro. Além disso, a abstração é umaprática útil ao refletir sobre projetos de software e ao comunicá-los, porque permite focalizaraspectos importantes, enquanto esconde ou ignora detalhes ruidosos. Uma linguagem visualcomo 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 doOMG (Object Management Group) desde 1997, e desde então tem sido aprimorada por estaorganização (BOOCH, RUMBAUGH e JACOBSON, 2000). UML pode ser empregada paravisualização, especificação, construção e documentação de artefatos de sistemas orientados aobjetos. Linguagens fornecem um vocabulário e as regras para a combinação das palavrasdesse vocabulário com a finalidade de comunicar algo. Da mesma forma, a UML contém umconjunto de símbolos gráficos, cada um com uma semântica bem definida. Isso visaminimizar a possibilidade de ambigüidades na interpretação de um modelo. Dessa forma, omodelo elaborado por um desenvolvedor pode ser lido por qualquer outro (ou por umaferramenta CASE) com facilidade de comunicação de idéias sobre o sistema que está sendomodelado. UML é apenas uma linguagem, ou notação, sendo, portando somente uma parte doprocesso de desenvolvimento de sistemas de software. A UML é independente demetodologia. Qualquer metodologia de desenvolvimento de sistemas que seja orientada aobjetos 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 aimplementaçã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 aplicativoJude, desenvolvido pela empresa Eiwa System Management. Esta empresa distribui oaplicativo em duas versões: a Community, que á gratuita; e a Professional, que é paga. Aversão paga possui suporte a outros tipos de digramas que não fazem parte da UML, comomapas mentais, além de outros recursos adicionais, como a possibilidade de criação dehiperligação entre diagramas (EIWA SYSTEM MANAGEMENT 2005). Esta não é uma das ferramentas mais maduras e completas do mercado, mas tem a seufavor uma interface com o usuário simples e familiar, além de relativa rapidez se comparadacom outras ferramentas deste estilo construídas em Java. Como qualquer aplicativo construídoem Java, Jude requer que a Máquina Virtual Java esteja instalada no computador. Esta
  25. 25. 25ferramenta 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 é VisualBasic.Net da empresa Microsoft. Diferente da versão anterior, Visual Basic 6.0, estacontempla uma quantidade bem mais abrangente de conceitos da programação orientada aobjetos, 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 Microsoftque, 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 virtualchamada Framework.Net, de forma semelhante a linguagem Java. Porém, a máquina virtualda Microsoft não é multiplataforma, funcionando apenas para o sistema operacional Windows98 em diante. Uma iniciativa da comunidade de software livre começou a implementar umamáquina virtual chamada Mono capaz de executar no sistema operacional GNU/Linux osprogramas compilados para o Framework.Net. O ambiente integrado de desenvolvimento utilizado será o Microsoft Visual Studio.Net2002. Este ambiente, como outros do tipo, permite a edição do código-fonte auxiliada porverificadores de sintaxe em tempo de digitação, compilação, depuração e distribuição doprograma.
  26. 26. 5 DESENVOLVIMENTO DA FERRAMENTA Nas seções seguintes, serão descritas as atividades realizadas e os produtos obtidosdurante o desenvolvimento do sistema de acordo com a definição apresentada no capítuloanterior. É importante salientar que a ordem de apresentação dos produtos dodesenvolvimento não necessariamente reflete a ordem em que estes foram realizados, pois, nametodologia adotada, muitas atividades ocorrem em paralelo, como, por exemplo, aconfecção simultânea e incremental dos diagramas de casos de uso, diagrama de pacotes ediagrama de classes.5.1 LEVANTAMENTO DOS CASOS DE USO O diagrama de casos de uso da UML permite mostrar atores (entidades de fora dosistema) utilizando o sistema de forma a produzir algum resultado observável e relevante doponto de vista do ator. No simulador de elevadores, o diagrama de casos de uso foi utilizadopara elucidar as tarefas que o usuário deseja executar no sistema, resultando na Figura 3.
  27. 27. 27 Figura 3 – Casos de uso do sistema O caso de uso “Simular” foi um dos primeiros a ser levantado por estar diretamenteligado 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 porsua vez acarretou o descobrimento dos demais casos de uso. Cada caso é detalhado a seguir:
  28. 28. 28 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 queum não pode ser realizado sem que o outro tenha sido realizado anteriormente. A dependênciaentre os casos de uso foi explicitada no diagrama da Figura 4. Na UML, a dependência entredois itens é representada por uma seta de ponta vazada e corpo tracejado. Esta dependênciafoi utilizada para definir a ordem de realização dos casos de uso, sendo o “Construir Prédio” oprimeiro deles.
  29. 29. 29 Figura 4 – Dependência entre os casos de uso Na seção seguinte, encontram-se as classes que foram projetadas para, trabalhando emconjunto, realizar os casos de uso.5.2 PACOTES BÁSICOS Na UML, um pacote serve para grupar itens afins. A metodologia Objectory prega adivisão das classes em três tipos: entidades, limites (ou apresentação) e controladoras. Aorganização de pacotes de classes adotada aqui foi inspirada nesta metodologia e é umasolução que pode ser adotada em qualquer projeto, independente do domínio de problema.Esta organização consiste em quatro pacotes básicos: • Entidades – contém as classes relativas ao domínio do problema em questão. Por exemplo, na modelagem de um sistema de vendas, este pacote é que deve conter classes como Cliente, Produto, Cupom, etc. A principal responsabilidade destas classes é representar as entidades pertencentes ao domínio do problema e a sua lógica. De forma alguma as classes deste pacote podem conter lógica e serviços relacionados à apresentação de informações, interface com o usuário ou comunicação com o meio exterior ao sistema; estas responsabilidades devem ser
  30. 30. 30 atribuídas às classes do pacote Apresentação. Estas classes normalmente se relacionam entre si e com as classes do pacote Serviços somente. • Controladores – estas classes coordenam atividades que normalmente possuem algum estado envolvendo alguns objetos Entidade. Segundo o exemplo de um sistema para vendas, uma classe controladora poderia ser CoordenadorVenda que seria responsável pela realização de vendas no sistema. Ela conteria o estado da venda corrente (esperando por produtos, esperando por pagamento, esperando por autorização de crédito, etc.) e coordenaria a ação entre os diferentes objetos entidades (cliente, produto, etc.). As classes controladoras dependem das classes entidades e das classes de serviço. As classes controladoras também são responsáveis por notificar os objetos que estejam interessados sobre alterações nos objetos entidades. • Apresentação – as classes deste pacote têm a responsabilidade de ser a interface entre o sistema e os usuários que interagem com ele (normalmente pessoas, mas podem ser também outros sistemas). Elas exibem as informações de objetos entidade e controladores para os usuários, e também transmitem ao sistema eventos que os usuários disparam. As classes de apresentação normalmente são extensões de classes genéricas de interface gráfica com usuário e contêm componentes como botões, listas e caixas de texto. Dependendo do sistema modelado, não existe uma interface com o usuário tipo teclado e monitor, mas mesmo assim são consideradas classes de apresentação as classes que fazem a comunicação com o meio externo, como as classes que controlam dispositivos de hardware (mostradores, luzes indicadoras, sensores, portas de comunicação, etc.). As classes de apresentação dependem de todas as outras, pois exibem informações sobre essas classes ou se utilizam dela de alguma maneira. • Serviços – neste pacote, estão classes altamente genéricas que resolvem problemas comuns que não são específicos de nenhum domínio. Por isso, essas classes são altamente reutilizáveis entre diferentes sistemas. As classes mais específicas (entidades, controladoras e de apresentação é que se valem delas para sua própria implementação). O desenvolvedor, na maioria dos casos, não cria muitas classes de serviço porque as plataformas de desenvolvimento já fornecem uma grande quantidade delas prontas para serem utilizadas. Classes que servem de interface entre o usuário e o sistema mas que ainda não foram personalizadas (através de herança ou composição) para um domínio específico de problema são consideradas como classes de serviço, como é o caso dos componentes de interface gráfica como botão, caixa de texto, janela, etc. O diagrama da Figura 5 mostra uma visão da organização dos pacotes básicos. Nosdiagramas UML, a representação gráfica do pacote é como uma pasta. Pacotes podem mostrardependências entre si, o que indica, na verdade, que alguns itens dentro de um pacote é quetêm alguma dependência com os itens dentro de outro pacote.
  31. 31. 31 Figura 5 – Divisão básica das classes em pacotes5.3 PACOTES ESPECÍFICOS DO SISTEMA Seguindo a divisão de pacotes básica mencionada na seção anterior, durante olevantamento dos casos de uso, foram encontrados conceitos relativos ao domínio que forammodelados 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 grandesafinidades e se dividiam em grupos bem distintos. Para representar essa característica dodomí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. Nassubseções seguintes, serão explorados cada um dos pacotes com suas devidas classes.
  32. 32. 32 Figura 6 – Pacotes para agrupar três grupos bem distintos de entidades5.3.1 Pacote Prédio Este pacote contém todo o conjunto de classes necessárias para configurar um prédioda simulação em termos das suas características físicas somente. Estas classes são totalmenteindependentes da existência (ou não) de um sistema de elevadores para este prédio e daconfiguração deste sistema. As classes deste pacote também não “tomam conhecimento” dapopulação que venha a habitar este prédio e suas características. O diagrama da Figura 7mostra 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 seuaspecto mais relevante é possuir um objeto da classe Pavimentos, que é uma coleção deobjetos Pavimento. O estereótipo “coleção” atribuído à classe Pavimentos foi utilizado aolongo da modelagem em outras classes também, e significa que a classe coleciona objetos deoutra classe, geralmente a com cardinalidade zero ou muitos (0..*) no relacionamento. Emtermos de implementação, este estereótipo significa que a classe terá diversas operaçõescomuns a coleções, como obter um item, contar a quantidade de itens colecionados, removerum 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 valorde nome corresponde ao seu índice em relação aos outros pavimentos, mas em certos prédios,alguns pavimentos têm nomes diferentes, como, por exemplo, o primeiro pavimento ser
  33. 33. 33chamado de “T” de térreo ou “P” de piso. As alturas dos pavimentos de um prédio muitasvezes 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 durantea simulação estão neste pacote. Como mostrado no diagrama de pacotes dos três grupos deentidades encontrados na modelagem, as classes de Pessoa têm uma dependência com asclasses do pacote prédio. E isto é natural se for analisado que as pessoas caminham peloprédio; as pessoas estão assentadas sobre o prédio; as pessoas usam o prédio. E como istoacontece 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 deelevadores com a necessidade de serviço de transporte. Esta necessidade surge pelo fato dapessoa estar em um pavimento, mas o pavimento que ela deseja ou precisa estar é outro acimaou abaixo. Na simulação, o usuário define uma faixa de tempo que será simulada e deveprogramar a chegada de pessoas dentro dessa faixa de tempo, sendo que cada pessoa está emum pavimento e tem como destino outro pavimento. Para realizar essas atribuições, foramprojetadas 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émcoleciona objetos Chegadas, sendo que cada objeto Chegadas está associado a um instante detempo dentro desta faixa. Um objeto Chegadas, por sua vez, coleciona objetos Chegada,
  34. 34. 34sendo cada objeto Chegada associado a um pavimento do Prédio ao qual aPopulacaoProgramada 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 aoqual Chegada está associado. Verificando a conexão dos objetos até agora, têm-se apossibilidade de programar nesta estrutura pessoas que chegam para solicitar serviço detransporte vertical em um dado instante de tempo a partir de um dado pavimento. Falta aprogramação de para onde essas pessoas desejam ir. Para implementar o pavimento destino das pessoas, a classe Pessoa está associada auma 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 umapessoa tenha mais de um pavimento destino dentro prédio, o que a faria usar o sistema deelevadores 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 representaadequadamente a realidade e permite criar qualquer tipo de população real no ambientesimulado. Porém, este modelo tem uma granularidade muito fina, pois tem um objeto Pessoapara cada pessoa que compõem a população de passageiros. O usuário do simulador perderiamuito tempo se tivesse que configurar no software cada uma desses objetos Pessoa para criara população desejada. Além disso, cada pessoa pode ter múltiplos destinos. A solução paraesse problema foi a criação de um gerador de população programada. Esse gerador é umobjeto da classe GeradorPopulacao que recebe uma parametrização de valores inteiros sobre apopulação de passageiros desejada e, quando invocada determinada operação, cria umapopulação programada com base nesses valores. Na implementação dessa classeGeradorPopulacao, devido a problemas no andamento do projeto, foi assumido com oobjetivo de simplificação que uma pessoa tem apenas um destino. Isto não foi feito pelaremoção do suporte da pessoa a múltiplos destinos. As pessoas somente não serãoconfiguradas com múltiplos destinos. A implementação da simulação da pessoa foi realizadacom suporte a múltiplos destinos. As Tabelas 1 e 2 ilustram como a classe GeradorPopulacao, que internamente tem umaestrutura semelhante, é parametrizada com valores numéricos e a partir destes gera apopulação de passageiros programada. As colunas representam os pavimentos de um prédio eas linhas, os instantes de chegadas de pessoas. As células contêm a quantidade de pessoas quechegam no instante indicado na linha e no pavimento indicado na coluna. Tabela 1 – Programação de Origens Pav. 1 Pav. 2 Pav. 3 Pav. 4 Pav. 5 Pav. 615/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
  35. 35. 35 Tabela 2 – Programação de Destinos Pav. 1 Pav. 2 Pav. 3 Pav. 4 Pav. 5 Pav. 615/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 maiorvolume, porém, mesmo assim, ela se torna pouco prática quando o usuário já possui umaquantidade 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 ostempos e pavimentos. Para tornar facilitada a geração de uma população a partir de umaquantidade de pessoas já definida, foi criada a classe GeradorPopulacaoRelativo. Esta classerecebe como parâmetros uma quantidade absoluta de pessoas e a distribuição dessas pessoasno tempo (instante de chegada) e espaço (pavimento). Essa distribuição é passada para aclasse através de porcentagens. Uma vez parametrizada, a classe pode criar, através dachamada de uma operação, um objeto GeradorPopulacao visto no parágrafo anterior e este porsua vez é que irá gerar a população programada, como indicado no diagrama da Figura 9. Figura 9 – Relação entre geradores de população e população programada Os passos para configurar um gerador de população relativo são os seguintes: 1. Informar a quantidade absoluta de pessoas; 2. Definir a distribuição dessas pessoas no tempo através de porcentagens; 3. Para cada chegada, definir a distribuição das pessoas daquele instante de chegada nos pavimentos através de porcentagens. Como já foi mencionado, o gerador de população relativo trabalha com porcentagens,e a sua estrutura interna é semelhante às Tabelas 3 e 4:
  36. 36. 36 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 quantidademuito grande de pequenos objetos, facilitando a sua tarefa, mas, em contrapartida, tiram dousuário a possibilidade de detalhamento. O ideal seria que o aplicativo permitisse a edição nosdiferentes níveis de detalhe, como o usuário desejar. Por exemplo, o usuário poderiaprogramar usar o gerador de população relativo para rapidamente configurar grande parte dapopulaçã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 depessoas que freqüentarão este espaço. Com base nisso, é possível estimar populações parafuturas edificações se é sabido de antemão o uso das áreas em questão. O simulador forneceao 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 daFigura 10.
  37. 37. 37 Figura 10 – Classes que representam relação entre uso e população estimada A interface IUsoPredio define as operações que são desejadas para um objeto quepode calcular uma população estimada. Outras classes realizam essa interface, porém cadaclasse com a sua própria lógica de cálculo. A principal operação é getTotal, que é justamentea quantidade de pessoas resultante do cálculo. Para efetuar o cálculo, cada classe temparâmetros específicos que o usuário irá informar. Por exemplo, UsoEscritorio precisa apenasda á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. Ainterface 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. Elarepresenta os diferentes usos de um prédio específico e tem operações que normalmente sãoimplementadas pela iteração pelos seus itens IUsoPredio, como, por exemplo, a obtenção dototal de pessoas estimadas com base nos usos do prédio. Esta operação tem o código-fonteexibido a seguir.
  38. 38. 38Public 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, esim serviços auxiliares para o usuário. Uma dessas classes é ValorDireto. Ela permite que ousuário entre com uma quantidade de população diretamente, sem nenhum cálculo, e é usadaquando o usuário sabe qual é a quantidade de pessoas ou estimou a quantidade de outro modoque não pelo programa. Além da quantidade o usuário pode opcionalmente entrar tambémcom 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 umaquantidade de unidades por uma quantidade de pessoas, sendo que essas duas informações sãodadas pelo usuário. Como foi dito, esse cálculo é muito simples e o próprio usuário poderiafazê-lo até mentalmente, mas a presteza dessa classe não é realizar o cálculo para o usuário esim, servir para documentar como o cálculo foi feito, para que, por exemplo, outro usuárioabra o arquivo realizado por outro e entenda qual a relação adotada no cálculo e até mesmopossa 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 desoftware, 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, umaprofundamento 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á queum sistema de elevadores está instalado em um prédio, e precisa de informações sobre esseprédio para funcionar. No diagrama da Figura 13, está uma visão geral das classes e suasrelações.
  39. 39. 39 Figura 13 – Visão geral das classes do pacote Elevador As classes Predio, Pavimentos e Pavimento que aparecem no diagrama pertencem aopacote Prédio. O papel de cada classe do pacote Elevador é demonstrado a seguir: • SistemaElevadores – é a classe que representa toda uma solução de elevação, servindo de “raiz” para as demais. Ela se relaciona com uma lógica de atendimento que controla a forma como o sistema despacha as chamadas dos passageiros. Possui uma coleção de elevadores. Contém configurações gerais do sistema como, por exemplo, capacidade de cabine, sendo que normalmente repassa essas configurações aos objetos interessados (objetos cabine, no caso citado). • Elevadores – agrega os elevadores de um sistema de elevadores. • Elevador – é um par poço e cabine, geralmente possui um nome identificador embora quase nunca o passageiro tenha essa informação. • Poco – representa o poço por onde a cabine corre. Estende-se ao longo dos pavimentos e possui configurações individuais por pavimento que são representadas pela classe PavimentoElevador, classe essa que o poço coleciona. • PavimentoElevador – contém qualquer configuração individual por pavimento que o poço precisa manter. Atualmente, esta classe só contém a informação sobre a existência ou não de uma porta de pavimento, mesmo assim, foi decido projetar poço como uma coleção de PavimentoElevador ao invés de uma coleção de valores booleanos (tem porta de pavimento ou não) visando acomodar melhor alterações e expansões que venham a surgir. Caso apareça uma nova configuração de pavimento, basta acrescentá-la na classe PavimentoElevador.
  40. 40. 40 • Cabine – transporta as pessoas. Contém toda a lógica de controle de movimento para subir e descer e de transferência de pessoas (entrada e saída). Possui também subcomponentes como a sua porta, que é um objeto do tipo PortaCabine. • PortaCabine – basicamente controla a abertura e fechamento. Todas as demais características da porta de cabine que são comuns a todas as portas de cabine estão em uma classe separada chamada TipoPortaCabine, e porta de cabine mantém uma referência para um objeto deste tipo. • TipoPortaCabine – contém as características de um tipo de porta de cabine. Estas características dizem respeito às dimensões da porta, velocidade de abertura, velocidade de fechamento, etc. • ILogicaAtendimento – é uma interface que define o que é esperado de um algoritmo de atendimento de chamadas de passageiros, também conhecido como algoritmo de despacho de chamadas. Outras classes é que irão realizar essa interface, sendo que cada classe pode implementar sua própria estratégia de atendimento.5.3.3.2 Lógica de Atendimento Assim como na computação existem diversos algoritmos diferentes para resolver omesmo problema, na engenharia de elevação existem diversas lógicas de atendimentodiferentes para coordenar o sistema de elevadores no atendimento de chamadas depassageiros. Diferentes lógicas de atendimento necessitam de diferentes periféricos paratrocar 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 deperiférico para coletá-los, ela trata com suposições. Essas suposições são baseadas no tipo detráfego de pessoas que a lógica espera atender, por isso, existem lógicas otimizadas paradiferentes tipos de tráfego. O uso de uma lógica de atendimento num ambiente onde o tráfegonã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 respeitode lógicas de atendimento. Porém o que há é a explicação da idéia básica para aimplementaçã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ãocolocadas nos produtos são mantidas em grande sigilo por cada indústria, já que é um recursochave para o desempenho do sistema de elevadores. O objetivo deste protótipo não é realizar a implementação fiel de alguma lógica deatendimento de alguma empresa específica, e sim desenvolver a arquitetura de um ambienteadequado de simulação de elevadores, onde é possível acomodar diferentes lógicas deatendimento. Este ambiente deve ser como uma “arena” onde se pode experimentar diferentestipos de soluções e verificar o seu desempenho. É objetivo deste trabalho tambémimplementar um protótipo deste ambiente para provar que é um projeto viável e que aarquitetura funciona adequadamente. Por isso, foi implementada apenas uma lógica deatendimento que foi baseada na lógica de atendimento chamada atendimento seletivo dedescida, descrita na bibliografia pesquisada (STRAKOSCH, 1998). Era prevista aimplementação de mais alguma lógica, mas devido a problemas de tempo no andamento doprojeto, elas não foram implementadas. Mesmo a assim, acredita-se que isto não comprometeo trabalho proposto uma vez que a lógica de atendimento, neste protótipo, tem apenas caráterilustrativo, já que ela foi implementada para ter o comportamento básico descrito na
  41. 41. 41bibliografia pesquisada, mas o restante, sobre o qual não se tem descrição, foi implementadopara o correto funcionamento, porém sem necessariamente representar a realidade de algumproduto específico de alguma empresa. Em um sistema com atendimento seletivo de descida, existe apenas um tipo de botãode chamada nos pavimentos, o do tipo que faz chamada de descida (embora o passageiro nopavimento possa querer subir). O elevador atende as chamadas sempre de cima para baixo, ouseja, ele sobe até a chamada de pavimento (ou de cabine) mais alta e desce atendendo asdemais chamadas até a chamada mais baixa. Então, o ciclo é reiniciado e o elevador sobenovamente para atender a chamada mais alta realizada neste meio tempo e desce atendendo asdemais. Esta lógica é apropriada para o tráfego de prédios residências, onde normalmente aspessoas 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 classeSeletivoDescida juntamente com a classe AtendenteSeletivoDescida. Um objetoSeletivoDescida cria para cada um dos elevadores do sistema um objeto AtendenteSeletivoDescida. Cada objeto AtendenteSeletivoDescida controla o seu próprio elevador e o objetoSeletivoDescida coordena todos os atendentes. Na simulação, não existem restrições nem detalhamentos relativos a aspectos dehardware, 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, semintermédio de periféricos. Para uma simulação correta, cada classe de lógica de atendimentosimulada 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ãocoletadas mais de uma chamada para o mesmo pavimento, logo, a lógica de atendimento nãosabe quantas pessoas estão esperando em cada pavimento, o que realmente acontece nosistema real. Outras limitações específicas desta lógica implementada são que o destino dachamada é informado somente na cabine (chamada de cabine) e a ausência de dispositivopesador para que se possa estimar quantidade de pessoas na cabine e se ela está lotada. Todasessas informações estão disponíveis no sistema, mas a lógica não as utiliza justamente parasimular a realidade. Em outras lógicas, talvez não haja alguma dessas limitações, então elapode se valer da informação correspondente livremente e muito provavelmente seja umalgoritmo que leva em consideração essa informação a mais para prover um melhoratendimento.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 umdiagrama 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 umnovo estudo ou abrir um estudo existente.
  42. 42. 42 Figura 14 – Estrutura do estudo no simulador Algumas classes de outros pacotes aparecem neste diagrama. Um detalhamento dasclasses é feito a seguir: • Sistema – classe relativa ao controle da aplicação em si. Pode-se dizer que é a “raiz” do aplicativo. • Estudo – como foi dito anteriormente, é o documento que o usuário irá criar e poderá salvar em arquivo. Possui três coleções que podem ser associadas a momentos distintos para o usuário: Predios, quando o usuário está construindo os objetos que poderão participar de simulações; Cenarios, quando o usuário seleciona objetos para participarem de uma simulação e executa a simulação; e Comparativos, depois de executadas diferentes simulações, elas são comparadas. • Prédios, Cenário e Comparativos – classes de coleção que armazenam e organizam objetos ItemPredio, Cenário e Comparativo respectivamente. Não possuem mais responsabilidades além destas. • ItemPredio – contém um predio (do pacote Predio), uma coleção de sistemas de elevadores e uma coleção de populações. • SistemasElevadores – coleciona os sistemas de elevadores que foram criados para o prédio do ItemPredio ao qual pertence. • Populações – coleciona as populações que foram criadas para o prédio do ItemPredio ao qual pertence.
  43. 43. 43 • ItemPopulacao – contém uma população programada e outros objetos relacionados a edição dessa população programada, como, por exemplo, um objeto GeradorPopulacaoRelativo. As classes Cenario e Comparativo serão explicadas a seguir de forma mais detalhada,com o auxílio do diagrama da Figura 15. Figura 15 – Classes Cenário e Comparativo Um objeto Cenário não passa de uma seleção de objetos que o usuário faz, visandoposteriormente executar a simulação com estes objetos. Como observado no diagrama daFigura 15, Cenário contém, de forma direta ou indireta, os objetos necessários para criar umasimulaçã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 posteriorcomparação de seus resultados (armazenados no objeto Relatório). O objeto cenário tem umaoperação chamada criaSimulacao que gera um objeto simulação configurado adequadamentecom os mesmos objetos do cenario. A classe simulação está no diagrama da Figura 16. Figura 16 – Classe simulação e seus relacionamentos
  44. 44. 44 O objeto simulação é que realmente é realiza a simulação. O objeto Cenário sómantém as configurações para posteriores simulações. A simulação possui um objeto Relógioque controla a passagem do tempo simulado. Relógio não se relaciona diretamente com oobjeto que deseja ouvir a passagem do tempo (simulação, nesse caso), mas sim, porintermédio de uma interface (IOuvinteRelogio) para evitar o acoplamento da classe relógiocom qualquer classe que deseje este serviço. Assim a classe relógio pode ser reaproveitada emoutros tipos de simulações e até em outros domínios de problema. A classe população contémas pessoas que estão atualmente (de acordo com o relógio) ativas na simulação. À medida queo tempo passa, a classe população remove pessoas que já chegaram aos seus destinos eadiciona as próximas pessoas programadas para chegar neste tempo, vindas da classePopulacaoProgramada. O objeto relatório é usado para armazenar os dados sobre a simulaçãoexecutada.5.4 EXECUÇÃO DA SIMULAÇÃO Os diagramas mostrados na seção anterior (diagramas de classe) mostram apenasaspectos estruturais do sistema, aspectos esses que são estáticos (BOOCH, RUMBAUGH eJACOBSON, 2000). Fazendo uma correlação com a implementação em alguma linguagem deprogramação, se pode dizer que aqueles diagramas estavam mais para tempo de compilaçãodo 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 deseqüência (BOOCH, RUMBAUGH e JACOBSON, 2000) e diagramas de estado. Será focadaapenas a execução da simulação no sistema, visto que é um dos aspectos mais relevantes doprojeto. 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 asimulação ocorra. O objeto Controlador mostrado, na implementação realizada, é umtemporizador que a cada estouro de tempo chama a operação passaTempo do relógio. Umaoutra alternativa de implementação poderia ser chamar a operação passaTempo do relógiodentro de um laço, o que tornaria a execução bem rápida, mas sem a possibilidade de ousuário observar o andamento da simulação; ou ainda, permitir que o usuário controle achamada da operação passaTempo do relógio através de uma tecla por exemplo. O ideal seriater as três opções para o usuário escolher de acordo com a sua necessidade.
  45. 45. 45 Figura 17 – Execução da simulação no objeto Simulação Quando o relógio tem a sua operação passaTempo invocada, ele incrementa o seutempo e notifica o seu atual ouvinte de que o tempo passou. Este ouvinte, no caso dosimulador de elevadores, é um objeto simulação. O objeto simulação por sua vez, quandoouve a notificação de passagem de tempo chama a sua rotina de simulação, que consistebasicamente de chamar a operação simula dos seus objetos SistemaElevadores e População. Odiagrama da Figura 18 é, de certa forma, uma continuação do diagrama anterior, expandindo oque acontece durante na operação simula do objeto SistemaElevadores.
  46. 46. 46 Figura 18 – Execução da simulação no objeto SistemaElevadores Os diagramas das Figuras 18 e 19 devem ser considerados como contínuos. Na suaoperação simula, o objeto SistemaElevador chama a operação simula da sua atual lógica deatendimento e dos seus elevadores. O objeto Elevadores, por sua vez, irá chamar simula paracada um dos seus elevadores. Cada Elevador solicita a simula para sua Cabine e esta solicitapara a sua porta. Figura 19 – Execução da simulação no objeto Elevadores
  47. 47. 47 Ao longo da simulação, certos objetos precisam manter alguma variável sobre o seuestado corrente. Este estado determina a ação que o objeto realiza na simulação, alterando oseu comportamento à medida que o tempo passa. Os objetos do sistema de elevadores quepossuem estado são Cabine e PortaCabine. Estes objetos e seus estados serão examinados aseguir, iniciando com Cabine. A Figura 20 é um diagrama de estados da UML. Cada retângulo com cantosarredondados representa um estado e as setas, a transição entre estes estados. O círculo apontapara o estado inicial. Como pode ser observado, o objeto Cabine inicia no estado ocioso. Esteestado indica que a cabine não recebeu nenhuma ordem para atender nenhum pavimentoainda, ou que a cabine terminou de atender o pavimento ordenado. Normalmente, é nesteestado que a cabine receberá ordens da lógica de atendimento para atender determinadopavimento. 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. Casocontrário, será iniciado o fechamento da porta de cabine através da mudança para o estadoFechandoPorta. 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 aindaum tempo necessário para que a cabine nivele o seu piso com o do pavimento. Durante estaação, ela está no estado Nivelando. Uma vez nivelada, a cabine abre a porta (mudança para oestado AbrindoPorta). Com a porta aberta, as pessoas começam e entrar e sair da cabine, quefica então no estado TransferindoPessoas. O tempo em que a cabine permanece no estadoTransferindoPessoas depende da quantidade de pessoas entrando e saindo dela, sendodiretamente proporcional. Terminada a transferência, a cabine volta para o estado Ocioso. Figura 20 – Estados do objeto Cabine
  48. 48. 48 A porta da cabine também possui estados durante a simulação. Estes estados sãomostrados no diagrama da Figura 21. Figura 21 – Estados do objeto PortaCabine A porta de cabine inicia no estado Aberta. Quando ela recebe uma ordem defechamento, entra então no estado Fechando, e permanecerá neste estado o tempo necessáriopara completar o seu fechamento. Quando está completamente fechada, passa para o estadoFechada e permanecerá neste estado até que receba uma ordem para abrir. Se a ordem paraabrir for dada, ocorre a mudança para o estado Abrindo, cuja permanência durará o temponecessário para abrir a porta. Uma vez que a abertura esteja completa, a porta volta para oestado Aberta. Como foi visto anteriormente, o objeto simulacao chama na sua rotina de simulação aoperaçã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 é ilustradono diagrama da Figura 22.
  49. 49. 49 Figura 22 – Execução da simulação no objeto Populacao A operação simula de População consiste em três tarefas. A primeira é remover aspessoas que já não têm mais pavimentos para ir, logo, não têm mais importância nasimulação. Isto é feito pela rotina removePessoasProntas, que pergunta para cada pessoa seela está finalizada e, em caso afirmativo, a remove. Outra tarefa é verificar a chegada de maispessoas à simulação. As chegadas dependem do tempo atual e do que foi programado naPopulacaoProgramada. Por isso, a populacao pede para PopulacaoProgramada as pessoas quedevem entrar no tempo atual através da operação obtemPessoas. As pessoas retornadas poresta operação são adicionadas na população. Por fim, a população itera sobre as pessoas queela mantém, chamando para cada uma a operação simula. A classe Pessoa passa por estados ao longo da simulação para controlar o seucomportamento. Estes estados são mostrados no diagrama da Figura 23.
  50. 50. 50 Figura 23 – Estados do objeto Pessoa O estado inicial da pessoa é Indefinido. Este estado indica que pessoa não sabe o quefazer 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á nestepavimento destino e se esse destino é alcançável pelo sistema de elevadores. Se ela constatarque precisa utilizar o sistema de elevadores, ela passa para o estado ChamandoElevador; docontrário, muda para o estado Pronto. Uma vez no estado ChamandoElevador, a pessoarealiza a chamada no sistema de elevadores, passando em seguida para o estadoEsperandoElevador. Neste meio tempo, a pessoa aguarda pelo elevador apropriado. Quandoela consegue entrar na cabine, muda então para o estado ViajandoElevador. Quando no estadoViajandoElevador, 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 cabinecompletando 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 oestado Indefinido, reiniciando o ciclo. Caso contrário, muda para o estado Finalizado, que é oestado final, indicado na UML por apontar para uma circunferência com um círculoconcêntrico. Quando um objeto entra no seu estado final não muda mais para nenhum outroestado, logo, no caso da pessoa, ela não executará mais nenhuma ação e será removida dapopulação como foi descrito anteriormente. Durante essas ações, a pessoa reporta dados sobre o desempenho do sistema durante oatendimento da sua chamada. Esses dados entram no objeto relatório da simulação e docenário para depois serem sumarizados e analisados. Os principais dados coletados são otempo de espera, que é o tempo desde de a chamada realizada no pavimento até a chegada da
  51. 51. 51cabine; e o tempo de viagem, que é o tempo que a pessoa passou dentro da cabine. O tempode espera e o tempo de viagem são os dados essenciais para a avaliação do desempenho de umsistema de elevadores. A soma desses dois dados resulta no tempo total que a pessoa usou osistema. Outros dados adicionais poderiam ser coletados por outros objetos, pela cabine, porexemplo. Mas isso já seria a adaptação para necessidades específicas de algum usuário ouempresa. Essa e outras personalizações poderão ser feitas se este protótipo vir a ser adotadopor alguma empresa como um projeto.
  52. 52. 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 umprotótipo utilizável. Certas qualidades desejáveis num produto final não foramimplementadas, como, por exemplo, vários conceitos relacionados à engenharia dausabilidade, bem como manual do usuário e documentação de ajuda. Justamente por não teras características de um produto final é que o projeto foi caracterizado como protótipo. Oprojeto 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 comoeste 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 deum exemplo de simulação. Já a seção seguinte faz uma correlação entre o simulador e ocálculo de tráfego.6.1 EXEMPLO DE SIMULAÇÃO A ferramenta será usada para avaliar o desempenho de duas soluções de elevaçãofrente 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. Napágina Prédios é que o usuário adiciona os objetos que posteriormente poderão participar deuma simulação. Estes objetos são prédio, população e sistema de elevadores. A adição é feitaatravés dos respectivos menus. A página prédios mostra uma estrutura de árvore, onde cadaprédio é uma raiz contendo a estrutura física, um conjunto de populações e um conjunto desistemas de elevadores pertencentes a este prédio. Isto reflete o que foi modelado e descritoanteriormente sobre um prédio poder ter mais uma população e mais de sistema deelevadores. A edição das características físicas de um prédio é mostrada na Figura 24. Todosos itens aparecendo na figura estão com os nomes sugeridos pelo programa, mas podem serrenomeados como o usuário desejar.
  53. 53. 53 Figura 24 – Edição da estrutura física de um prédio Na edição da população, deve ser informada a quantidade de pessoas no prédio. Isso éfeito adicionando-se usos ao prédio. Caso a quantidade de pessoas seja conhecida, utiliza-se otipo de uso valor direto, que na verdade não é um tipo de uso. Ele permite que o usuário digiteo valor desejado diretamente. Se não se sabe a quantidade de pessoas, ela pode ser estimadacom 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 depessoas.
  54. 54. 54 Figura 25 – Estimativa da população baseada nos usos do prédio Uma vez definida a quantidade de pessoas da população, o usuário distribui essaspessoas em momentos de chegada. Isso é feito clicando num gráfico que tem no eixo X alinha de tempo da simulação. Essa linha de tempo pode ser editada quanto ao início, fim e asua escala. A Figura 26 mostra a distribuição das chegadas para a população do exemplo. Deforma, semelhante é feita a distribuição de cada chegada pelos pavimentos, sendo umadistribuição para a origem e outra para o destino.
  55. 55. 55 Figura 26 – Distribuição das pessoas em momentos de chegada A edição do sistema de elevadores é mostrada na Figura 27. Foram criados doissistemas para o exemplo. O Sistema 1 possui dois elevadores com cabines de capacidade de15 pessoas. Já o Sistema 2, possui três elevadores com cabines de capacidade de 10 pessoas.As configurações restantes são iguais entre os dois sistemas.
  56. 56. 56 Figura 27 – Edição do sistema de elevadores Na página Cenários, o usuário pode selecionar itens que ele criou e editou na páginaprédios para serem simulados juntos, o que no sistema é chamado de cenário. Os cenários sãoexibidos em uma lista, como mostrado na Figura 28. Criar um cenário não faz com que asimulação seja iniciada, apenas permite manter a configuração necessária para iniciar asimulação a partir do cenário. Pode-se dizer que, no programa, a simulação é o cenário emexecução. Só é possível criar um cenário se existe pelo menos um prédio com uma populaçãoe com um sistema de elevadores. Para o exemplo, foram criados dois cenários. Ambospossuem o mesmo prédio e população. A diferença está no sistema de elevadores: o Cenário 1utiliza o Sistema 1 e o Cenário 2, o Sistema 1. A Figura 28 mostra o Cenário 1 com asimulação sendo executada.
  57. 57. 57 Figura 28 – Cenário com simulação em execução Os números na coluna pessoas indicam a quantidade de pessoas aguardando peloelevador no respectivo pavimento. As cabines são representadas pelos colchetes, sendo que onúmero entre eles é a quantidade de pessoas dentro da cabine. As setas laterais aparecemquando a porta da cabine está abrindo ou fechando. Os comparativos são criados selecionando-se cenários existentes para que osresultados de suas simulações sejam confrontados. Os comparativos são criados e exibidosnuma lista na página Comparativos do programa. A janela de comparativo exibe o resultadode cada um dos cenários do comparativo, que normalmente é exibido em um gráfico separadona 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 deviagem ou tempo total (tempo de espera + tempo de viagem). Também é possível selecionar aforma de agregaçÀ

×