Mjukvarudesign för ett hissystem

De flesta utvecklare har arbetat med vissa moduler under sin karriär, är det svårt för dem att förstå och implementera en komplett programvarudesign, men jag tror att alla kan lära sig!!

Note: För iOS-intervjufrågor, kolla den här länken – Top iOS Interview Questions You Must Prepare In 2018

Panel: Du: Snälla, berätta för mig hur ett hissystem ska utformas.

Du: Detta är en ganska bred fråga.

Från applikationsutvecklarens perspektiv bör vi berätta om klasserna och deras relation, klassdiagram & Sekvensflöde. Vi känner alla till tidsbristen under en teknisk diskussion och ibland är det svårt vad den andra killen förväntar sig av oss.

I ett allmänt perspektiv kan det vara möjligt att din panel är intresserad av backend-design så du måste klargöra med honom, vad förväntar de sig av dig?

En ögonblicksbild av hissstyrsystemet

Vår hiss har den grundläggande funktionen som alla hissystem har, såsom att gå upp och ner, öppna och stänga dörrar och naturligtvis plocka upp passagerare.

Hissen är tänkt att användas i en byggnad som har våningar numrerade från 1 till MaxFloor, där den första våningen är lobbyn. Det finns knappar för att anropa hissen i hisskorgen som motsvarar varje våningsplan. För varje våning utom den översta våningen och lobbyn finns det två hallknapparna som passagerarna kan ringa för att gå upp och ner. På översta våningen finns det bara en knapp för att ringa nedåt och en knapp för att ringa uppåt i lobbyn. När bilen stannar på en våning öppnas dörrarna och bilens lykta som visar i vilken riktning bilen körs tänds så att passagerarna kan få veta i vilken riktning bilen rör sig för tillfället. Bilen rör sig snabbt mellan våningarna, men den bör kunna sakta ner tillräckligt tidigt för att stanna vid en önskad våning. För att intyga systemets säkerhet kommer nödbromsen att utlösas och bilen kommer att tvingas stanna under alla osäkra förhållanden.

Alla system interagerar med mänskliga eller automatiserade aktörer som använder systemet i något syfte, och både människor och aktörer förväntar sig att systemet ska bete sig på ett förutsägbart sätt.

Det finns sju användningsfall som baseras på hissystemets nuvarande krav, vilket visas i figur 1:

• Behandla samtal om hiss/bil: Detta användningsfall omfattar flera scenarier som kommer att beskrivas i detalj i senare avsnitt av detta dokument. Dessa scenarier omfattar att hissen tar emot hiss- och bilsamtal från passagerarna, tänder eller släcker ljuset på hiss- och bilsamtalsknapparna, uppdaterar den registrering av hiss- och bilsamtal som finns lagrad i systemets kontrolldelar, etc.
• Behandla hallsamtal: Liknande behandling av hiss- och bilsamtal, men i detta användningsfall ingår att hissen tar emot hallsamtal från passagerarna, tänder eller släcker ljuset på hallsamtalsknapparna, uppdaterar registret över hallsamtal i systemkontrolldelarna osv.
• Flytta/stoppa hissen: En hiss har som huvudfunktion att ändra körhastighet, fatta beslut om att stanna och ange körriktning för bilen.
• Indikering av rörelseriktning: Hissen bör ha denna mekanism för att låta passagerarna veta vilken riktning som hisskorgen har för tillfället, så att passagerarna kan besluta om de vill gå in i hisskorgen eller inte.
• Indikering av hisskorgens position: På samma sätt bör hissen låta passagerarna veta om deras destinationsvåning är nådd, så att passagerarna kan besluta att lämna hissen.
• Öppna/stäng dörrarna: Hissen ska kunna öppna och stänga dörrarna så att passagerarna kan gå in och ut ur hissen. Funktionsområdena i detta användningsfall bör också göra det möjligt för passagerarna att göra dörrvändningar när dörrarna stängs och passageraren vill gå in i hisskorgen.
• Utlösa nödbroms: Det finns en säkerhetsmekanism i hissen för att se till att ett osäkert tillstånd inte genereras övergående.

Med denna stora förståelse för hissystemet kan vi börja identifiera de klasser som krävs för att utforma ett system.

Identifiering av klasser/objekt:

• ElevatorControl: Detta är en funktion som gör det möjligt att identifiera en klass som är nödvändig för att utforma ett system: Det centrala kontrollobjektet i hissystemet. ElevatorControl kommunicerar och kontrollerar alla andra objekt i systemet.
• Dörr: ElevatorControl: Det finns två dörrar i systemet, ”gud”-objektet – ElevatorControl – beordrar dörrarna att öppnas och stängas.
• Bil/hiss: Bilen styrs så att den rör sig uppåt och nedåt (i olika hastigheter) och stannar vid våningar vid behov.
• Knapp: ElevatorControl-klassen styr också knappklassen, som ytterligare generaliserar två underklasser CarCallButton och HallCallButton. Kontrollobjektet kommunicerar med knappobjekten, får information om huruvida en knapp är nedtryckt och styr i sin tur belysningen av knapplamporna.
• Indikator: Det finns två typer av indikatorer i systemet, CarPositionIndicator och CarDirectionIndicator (dvs. CarLantern). Indikatorerna styrs för att visa information om bilens aktuella position och rörelseriktning.
• Säkerhet: Närhelst en nödsituation inträffar, beordrar ElevatorControl Safety

Controller-klasserna:

• DoorControl kontrollerar DoorMotorns funktion. DoorMotor kan kommenderas att öppna, stänga eller göra en dörrvändning.
• DriveControl styr hissdriften, som fungerar som huvudmotor som förflyttar hisskorgen uppåt och nedåt och stannar vid våningar vid behov.
• LanternControl finns i två stycken, CarPositionIndicator och CarDirectionIndicator.
• HallButtonControl finns i ett par på varje våning, där den ena styr uppåt HallCallButton och den andra nedåt. HallButtonControl accepterar tryck på hallknapparna och ger återkoppling till hallknappslamporna.
• CarButtonControl finns en för varje våningsplan och alla är placerade i hissen/vagnen. CarButtonControl tar emot CarCallButton-anrop och ansvarar för att tända/släcka motsvarande lampor i hissen/vagnen.
• CarPositionIndicator ger värde till CarPositionIndicator så att passagerarna kan känna till hissens/vagnen aktuella position.
• Dispatcher kontrollerar inte de faktiska hissdelarna, men den är viktig i programvarusystemet. Det finns en Dispatcher för varje hiss/korg, vars huvudfunktion är att beräkna målrörelseriktningen och destinationen för hissen/korgen samt att upprätthålla öppningstiden för dörrarna. Dispatcher interagerar med nästan alla kontrollobjekt i systemet utom LanternControl.

Hoppas att allting går bra fram till nu, låt oss förstå allt med några av sekvensdiagrammen.

Sekvensflöde

Det kan vara svårt att förklara muntligt men om du tydligt förstår hur det kommer att fungera kan du rita några sekvensdiagram och försöka förklara flödet med några exempel parallellt.

1. Process hall calls : Det finns två scenarier för detta användningsfall:
   1.1 hissen rör sig i samma riktning som passagerarens destination
   1.2 hissen rör sig i motsatt riktning som passagerarens destination
   1.2 hissen rör sig i motsatt riktning som passagerarens destination
   1.2 hissen rör sig i motsatt riktning som passagerarens destination.

2. Flytta/stoppa bilen:

3. Ange rörelseriktning:

4. Utlösa nödbromsen : Det finns fem scenarier för detta användningsfall:

1. Om bilen beordras att stanna men inte stannar vid önskat golv utlöses nödbromsen.

2. Om bilen beordras att röra sig men inte rör sig utlöses nödbromsen.

3. Om dörrarna beordras att öppnas när bilen stannar på en våning, men dörrarna inte öppnas, utlöses nödbromsen.

4. Om dörrarna öppnas när bilen rör sig, utlöses nödbromsen.

5. Om bilen fortsätter att köra när gränsen för lyftvägen är nådd utlöses nödbromsen.

Jag kommer att visa endast ett sekvensdiagram för fall 5.

Jag förväntar mig att de flesta av sakerna kommer att bli en bild i ditt sinne och lätt att komma ihåg samt förklara. För backend design , följ System Design serien

Hoppar att du gillar förklaringen. För fler designfrågor , vänligen vänta och följ mig.