utilizando usando sistemas sistema poo paradigma orientado objetos método metodologia informáticos estructurado escuelait diseño curso análisis analisis adoo oop design-patterns design language-agnostic

oop - usando - método de análisis y diseño orientado a objetos



Modelado de un ascensor utilizando Análisis y Diseño Orientado a Objetos (7)

Hay un conjunto de preguntas que parecen ser comúnmente utilizadas en entrevistas y clases cuando se trata de diseño y análisis orientado a objetos. Este es uno de ellos; desafortunadamente, mi profesor de POO en la universidad nunca me dio una respuesta, y me lo he estado preguntando.

El problema es el siguiente: diseñar un conjunto básico de objetos / métodos que se utilizarán para simular un banco elevador. ¿Cuáles son los objetos y sus atributos / métodos?

En aras de la discusión, supongamos que nuestro edificio tiene veinte pisos; el piso inferior es el vestíbulo, y el segundo piso se conecta con el estacionamiento (por lo tanto, las personas entrarán / saldrán del edificio en el piso inferior o en el segundo piso). Hay un banco elevador que da servicio a todas las plantas; hay tres pozos de ascensor en el banco de ascensores, y un elevador por eje.

¿Cuál sería la forma correcta de modelar esto en un modelo orientado a objetos?


He visto muchas variantes de este problema. Una de las principales diferencias (que determina la dificultad) es si hay algún intento centralizado de tener un "sistema inteligente y eficiente" que tenga equilibrio de carga (por ejemplo, enviar más ascensores inactivos para cabildear en la mañana). Si ese es el caso, el diseño incluirá un subsistema completo con un diseño realmente divertido.

Un diseño completo es, obviamente, demasiado para presentar aquí y hay muchas alternativas. La amplitud tampoco está clara. En una entrevista, intentarán descubrir cómo pensarías. Sin embargo, estas son algunas de las cosas que necesitaría:

  1. Representación del controlador central (suponiendo que haya uno).

  2. Representaciones de ascensores

  3. Representaciones de las unidades de interfaz del ascensor (pueden ser diferentes de ascensor a ascensor). Obviamente también botones de llamada en cada piso, etc.

  4. Representaciones de las flechas o indicadores en cada piso (casi una "vista" del modelo de elevador).

  5. Representación de un ser humano y carga (puede ser importante para tener en cuenta las cargas máximas)

  6. Representación del edificio (en algunos casos, ya que ciertos pisos pueden estar bloqueados a veces, etc.)


Lo principal de lo que preocuparse es cómo notificaría al elevador que necesita subir o bajar. y también si va a tener una clase centralizada para controlar este comportamiento y cómo podría distribuir el control.

Parece que puede ser muy simple o muy complicado. Si no tomamos la simultaneidad o el tiempo para que un ascensor llegue a un lugar, entonces parece que será sencillo, ya que solo necesitamos verificar los estados del elevador, como si se moviera hacia arriba o hacia abajo, o si estuviera parado. Pero si hacemos que Elevator implemente Runnable, y constantemente verificamos y sincronizamos una cola (linkedList). Una clase de controlador asignará qué piso ir a la cola. Cuando la cola está vacía, el método run () esperará (queue.wait ()), cuando se asigne un piso a este elevador, llamará a queue.notify () para activar el método run () y ejecutar ( ) método llamará a goToFloor (queue.pop ()). Esto hará que el problema sea demasiado complicado. Traté de escribirlo en papel, pero no creo que funcione. Parece que en realidad no necesitamos tener en cuenta la concurrencia o el problema de temporización aquí, pero sí tenemos que usar una cola para distribuir el control.

¿Cualquier sugerencia?


Primero hay una clase de ascensor. Tiene una dirección (arriba, abajo, stand, mantenimiento), un piso actual y una lista de solicitudes de piso ordenadas en la dirección. Recibe solicitud de este ascensor.

Luego hay un banco. Contiene los ascensores y recibe las solicitudes de los pisos. Estos están programados para todos los ascensores activos (no en mantenimiento).

La programación será como:

  • si está disponible, elija un elevador de pie para este piso.
  • de lo contrario, elija un elevador que se mueva a este piso.
  • si no, elige un elevador de pie en otro piso.
  • de lo contrario, elija el elevador con la carga más baja.

Cada elevador tiene un conjunto de estados.

  • Mantenimiento: el elevador no reacciona a las señales externas (solo a sus propias señales).
  • Soporte: el elevador está fijo en un piso. Si recibe una llamada. Y el ascensor está en ese piso, las puertas se abren. Si está en otro piso, se mueve en esa dirección.
  • Arriba: el ascensor se mueve hacia arriba. Cada vez que alcanza un piso, verifica si necesita detenerse. Si es así, se detiene y abre las puertas. Espera una cierta cantidad de tiempo y cierra la puerta (a menos que algo se mueva a través de ellos. Luego quita el piso de la lista de solicitudes y verifica si hay otra solicitud. Si es así, el elevador comienza a moverse nuevamente. estado de pie.
  • Abajo: como hacia arriba pero en dirección inversa.

Hay señales adicionales:

  • alarma. El ascensor se detiene. Y si está en un piso, las puertas se abren, la lista de solicitudes se borra, las solicitudes vuelven al banco.
  • puerta abierta. Abre las puertas si un elevador está en el piso y no se mueve.
  • la puerta se cierra. Cerré la puerta si están abiertos.

EDITAR: Algunos ascensores no comienzan en bottom / first_floor esp. en caso de rascacielos.

min_floor y max_floor son dos atributos adicionales para Elevator.



Se debe considerar algo al Designing el sistema de elevadores

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 pulsación de botón da como resultado una solicitud de ascensor que debe ser servida. Cada una de estas solicitudes se rastrea en un lugar global

La cantidad de ascensores en el edificio será determinada por el usuario. El edificio contendrá una cantidad fija de pisos. La cantidad de pasajeros que pueden caber en el elevador será reparada. Los pasajeros se contarán cuando salgan del ascensor en su piso de destino. El piso de destino se determinará usando un intervalo de Poisson "aleatorio". Cuando todos los pasajeros en el ascensor hayan llegado a su piso de destino, el elevador regresará al vestíbulo para recoger a más pasajeros


The Art of Computer Programming Vol.1 de Donald Knuth tiene una demostración del ascensor y las estructuras de datos. Knuth presenta una discusión y un programa muy completo.

Knuth (1997) "Information Structures", The Art of Computer Programming, vol. 1 pp.302-308


Ver:

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

link