Modelowanie windy przy użyciu analizy i projektowania zorientowanego obiektowo [zamknięte]

Istnieje zestaw pytań, które wydają się być powszechnie używane w wywiadach i na zajęciach, jeśli chodzi o projektowanie i analizę zorientowaną obiektowo. To jest jeden z nich; Niestety, mój profesor OOP na studiach nigdy tak naprawdę nie udzielił odpowiedzi, więc się zastanawiałem.

Problem jest następujący: zaprojektować podstawowy zestaw obiektów / metod, które mają być użyte do symulacji windy. Jakie są obiekty i ich atrybuty / metody?

Dla celów argumentacji załóżmy, że nasz budynek ma dwadzieścia pięter; dolne piętro to hol, a drugie piętro łączy się z garażem (w związku z tym ludzie będą wchodzić / wychodzić z budynku na parterze lub na drugim piętrze). Jest jedna winda obsługująca wszystkie piętra; w zespole wind są trzy szyby wind i jedna winda na szyb.

Jaki byłby właściwy sposób modelowania tego w modelu zorientowanym obiektowo?

Najpierw jest klasa windy. Ma kierunek (w górę, w dół, stoisko, konserwacja), bieżące piętro i listę żądań pięter posortowanych w kierunku. Otrzymuje żądanie z tej windy.

Jest też bank. Zawiera windy i odbiera żądania z pięter. Są one zaplanowane dla wszystkich aktywnych wind (nie w konserwacji).

Harmonogram będzie wyglądał następująco:

• jeśli jest dostępna, wybierz stojącą windę dla tego piętra.
• w przeciwnym razie wybierz windę jadącą na to piętro.
• w przeciwnym razie wybierz stojącą windę na innym piętrze.
• w przeciwnym razie wybierz windę z najmniejszym obciążeniem.

Każda winda ma zestaw stanów.

• Konserwacja: winda nie reaguje na sygnały zewnętrzne (tylko na własne sygnały).
• Stojak: winda jest przymocowana do podłogi. Jeśli otrzyma połączenie. Winda jest na tym piętrze, drzwi się otwierają. Jeśli jest na innym piętrze, porusza się w tym kierunku.
• W górę: winda jedzie w górę. Za każdym razem, gdy dociera do podłogi, sprawdza, czy musi się zatrzymać. Jeśli tak, zatrzymuje się i otwiera drzwi. Czeka przez określony czas i zamyka drzwi (chyba że coś przez nie przechodzi. Następnie usuwa podłogę z listy żądań i sprawdza, czy jest inne żądanie. Jeśli tak, winda rusza ponownie. Jeśli nie, wjeżdża do Stanowisko państwowe.
• W dół: jak w górę, ale w odwrotnym kierunku.

Istnieją dodatkowe sygnały:

• alarm. Winda się zatrzymuje. A jeśli jest na podłodze, drzwi się otwierają, lista zgłoszeń jest czyszczona, a wnioski wracają do banku.
• drzwi otwarte. Otwiera drzwi, jeśli winda jest na podłodze i się nie porusza.
• drzwi się zamykają. Zamknięte drzwi, jeśli są otwarte.
  

EDYCJA: Niektóre windy nie zaczynają się od dołu / pierwszego piętra, zwł. w przypadku drapaczy chmur.

min_floor i max_floor to dwa dodatkowe atrybuty dla windy.

Donald Knuth's The Art of Computer Programming, tom 1, zawiera demonstrację windy i struktur danych. Knuth przedstawia bardzo szczegółową dyskusję i program.

Knuth (1997) „Struktury informacyjne”, The Art of Computer Programming Vol. 1 pp.302-308

Widziałem wiele wariantów tego problemu. Jedną z głównych różnic (która determinuje trudność) jest to, czy istnieje jakaś scentralizowana próba posiadania „inteligentnego i wydajnego systemu”, który miałby równoważenie obciążenia (np. Wysłanie rano większej liczby niedziałających wind do lobby). W takim przypadku projekt będzie zawierał cały podsystem z naprawdę zabawnym projektem.

Pełny projekt to oczywiście zbyt wiele, aby go tu przedstawić, a alternatyw jest wiele. Szerokość również nie jest jasna. W wywiadzie spróbują dowiedzieć się, jak myślisz. Oto kilka rzeczy, których potrzebujesz:

1. Reprezentacja sterownika centralnego (przy założeniu, że taki istnieje).

2. Reprezentacje wind

3. Reprezentacje jednostek interfejsowych windy (mogą się różnić w zależności od windy). Oczywiście również przyciski wywołania na każdym piętrze itp.

4. Reprezentacje strzałek lub wskaźników na każdym piętrze (prawie „widok” modelu windy).

5. Reprezentacja człowieka i ładunku (może mieć znaczenie przy uwzględnieniu maksymalnych obciążeń)

6. Reprezentacja budynku (w niektórych przypadkach, ponieważ niektóre piętra mogą być czasami blokowane itp.)

Widzieć:

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

połączyć

Szczegółowa odpowiedź:

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

Należy wziąć pod uwagę podczas projektowania systemu windy,

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

Każde naciśnięcie przycisku powoduje żądanie windy, która musi zostać obsłużona. Każde z tych żądań jest śledzone w globalnym miejscu

Liczba wind w budynku zostanie określona przez użytkownika. Budynek będzie miał stałą liczbę kondygnacji. Liczba pasażerów, która może zmieścić się w windzie zostanie ustalona. Pasażerowie będą liczeni, gdy opuszczą windę na docelowym piętrze. Piętro docelowe zostanie określone przy użyciu „losowego” przedziału Poissona. Gdy wszyscy pasażerowie windy dotrą na piętra docelowe, winda wróci do holu, aby zabrać więcej pasażerów

Najważniejsze jest to, w jaki sposób powiadomisz windę, że musi się poruszać w górę lub w dół. a także, jeśli zamierzasz mieć scentralizowaną klasę do kontrolowania tego zachowania i jak możesz dystrybuować tę kontrolę.

Wydaje się, że może to być bardzo proste lub bardzo skomplikowane. Jeśli nie weźmiemy współbieżności lub czasu, aby winda dotarła do jednego miejsca, wydaje się, że będzie to proste, ponieważ musimy tylko sprawdzić stany windy, na przykład czy porusza się w górę, w dół lub stoi w miejscu. Ale jeśli sprawimy, że Elevator zaimplementuje Runnable i będzie stale sprawdzać i synchronizować kolejkę (linkedList). Klasa kontrolera przypisze piętro, które ma trafić w kolejce. Gdy kolejka jest pusta, metoda run () będzie czekać (queue.wait ()), kiedy piętro zostanie przypisane do tej windy, wywoła queue.notify () w celu wybudzenia metody run () i uruchomi ( ) wywoła metodę goToFloor (queue.pop ()). To spowoduje, że problem będzie zbyt skomplikowany. Próbowałem napisać to na papierze, ale nie sądzę, żeby to działało. Wygląda na to, że tak naprawdę nie musimy brać pod uwagę kwestii współbieżności lub czasu,

Jakieś sugestie?