Modelando um elevador usando Análise e Design Orientados a Objetos [fechado]

Há um conjunto de perguntas que parecem ser comumente usadas em entrevistas e aulas quando se trata de design e análise orientados a objetos. Este é um deles; infelizmente, meu professor de POO na faculdade nunca deu uma resposta para isso, e por isso fiquei pensando.

O problema é o seguinte: projete um conjunto básico de objetos / métodos a serem usados ​​para simular um banco de elevadores. Quais são os objetos e seus atributos / métodos?

Por uma questão de argumento, vamos supor que nosso prédio tenha vinte andares; o piso inferior é o saguão e o segundo andar se conecta à garagem (portanto, as pessoas entram / saem do prédio no piso inferior ou no segundo andar). Há um banco de elevador que atende todos os andares; existem três eixos de elevador no banco de elevadores e um elevador por eixo.

Qual seria a maneira correta de modelar isso em um modelo orientado a objetos?

Primeiro, há uma classe de elevador. Possui uma direção (para cima, para baixo, suporte, manutenção), um piso atual e uma lista de solicitações de piso classificadas na direção. Ele recebe solicitação deste elevador.

Depois, há um banco. Ele contém os elevadores e recebe os pedidos dos andares. Eles estão programados para todos os elevadores ativos (não em manutenção).

O agendamento será como:

• se disponível, escolha um elevador de pé para este andar.
• mais escolha um elevador movendo-se para este andar.
• mais escolha um elevador de pé em outro andar.
• mais escolha o elevador com a carga mais baixa.

Cada elevador tem um conjunto de estados.

• Manutenção: o elevador não reage a sinais externos (apenas a seus próprios sinais).
• Suporte: o elevador está fixo no chão. Se receber uma chamada. E o elevador está naquele andar, as portas se abrem. Se estiver em outro andar, ele se move nessa direção.
• Para cima: o elevador sobe. Cada vez que atinge um piso, verifica se precisa parar. Nesse caso, ele para e abre as portas. Ele espera por um certo período de tempo e fecha a porta (a menos que algo esteja se movendo através deles. Em seguida, remove o piso da lista de solicitações e verifica se há outra solicitação. Nesse caso, o elevador começa a se mover novamente. Caso contrário, ele entra no posição do estado.
• Para baixo: como para cima, mas na direção inversa.

Existem sinais adicionais:

• alarme. O elevador para. E se estiver no piso, as portas se abrirem, a lista de solicitações será limpa, as solicitações retornadas ao banco.
• porta aberta. Abre as portas se um elevador estiver no chão e não se mover.
• porta se fecha. Fechou a porta se estiver aberta.
  

EDIT: Alguns elevadores não começam no bottom / first_floor esp. no caso de arranha-céus.

min_floor e max_floor são dois atributos adicionais para o Elevador.

A Arte da Programação por Computador Vol.1 de Donald Knuth tem uma demonstração do elevador e das estruturas de dados. Knuth apresenta uma discussão e um programa muito completos.

Knuth (1997) "estruturas de informação", The Art of Computer Programming vol. 1 pp.302-308

Eu já vi muitas variantes desse problema. Uma das principais diferenças (que determina a dificuldade) é se existe alguma tentativa centralizada de ter um "sistema inteligente e eficiente" com balanceamento de carga (por exemplo, envie mais elevadores inativos para fazer lobby pela manhã). Se for esse o caso, o design incluirá um subsistema inteiro com um design realmente divertido.

Obviamente, um design completo é demais para apresentar aqui e existem muitas alternativas. A largura também não é clara. Em uma entrevista, eles tentarão descobrir como você pensaria. No entanto, estas são algumas das coisas que você precisa:

1. Representação do controlador central (assumindo que exista um).

2. Representações de elevadores

3. Representações das unidades de interface do elevador (elas podem ser diferentes de elevador para elevador). Obviamente, também chame botões em todos os andares, etc.

4. Representações das setas ou indicadores em cada andar (quase uma "vista" do modelo do elevador).

5. Representação de um ser humano e de uma carga (pode ser importante para calcular a carga máxima)

6. Representação do edifício (em alguns casos, porque determinados andares podem ser bloqueados às vezes etc.)

Vejo:

Lu Luo, A UML Documentation for a Elevator System
Distributed Embedded Systems, Fall 2000
Ph.D. Project Report
Carneghie Mellon University

ligação

Resposta detalhada:

http://www.angelfire.com/trek/software/elevator.html

O que você deve considerar ao projetar o sistema do elevador,

Elevator
Floor/Location Identifier
Number of steps
Rotation speed
Daterange
InstallationDate
MaintainenceDate
Department Identifier
AllowedWeight
Detail / Description
Poison Ratio (Statistics)
Start
Stop
SetDirection
SetRotationSpeed
EmergencyStop = Stop + Alert
EmergencyAccidentSenser Handler

Cada pressão no botão resulta em uma solicitação de elevador que deve ser atendida. Cada uma dessas solicitações é rastreada em um local global

O número de elevadores no edifício será determinado pelo usuário. O edifício conterá um número fixo de andares. O número de passageiros que podem caber no elevador será fixo. Os passageiros serão contados quando deixarem o elevador no andar de destino. O piso de destino será determinado usando um intervalo Poisson "aleatório". Quando todos os passageiros no elevador atingirem o piso de destino, o elevador retornará ao saguão para pegar mais passageiros

A principal coisa a se preocupar é como você notificaria o elevador de que ele precisa subir ou descer. e também se você tiver uma classe centralizada para controlar esse comportamento e como você pode distribuir o controle.

Parece que pode ser muito simples ou muito complicado. Se não considerarmos a simultaneidade ou o tempo para um elevador chegar a um lugar, parece que será simples, pois precisamos apenas verificar os estados do elevador, como se ele estivesse subindo ou descendo, ou parado. Mas se fizermos o Elevator implementar Runnable e constantemente verificar e sincronizar uma fila (linkedList). Uma classe Controller atribuirá qual andar seguir na fila. Quando a fila estiver vazia, o método run () aguardará (queue.wait ()), quando um andar for atribuído a esse elevador, ele chamará queue.notify () para ativar o método run () e execute ( ) chamará goToFloor (queue.pop ()). Isso tornará o problema muito complicado. Tentei escrever no papel, mas não acho que funcione. Parece que realmente não precisamos levar em consideração problemas de concorrência ou de tempo aqui,

Alguma sugestão?