Softwaredesign til et elevatorsystem

Som de fleste udviklere har arbejdet med nogle moduler i løbet af deres karriere, er det svært for dem at forstå og implementere et komplet design for en software, men jeg tror, at alle kan lære det!!

Note: For iOS-interview spørgsmål, tjek dette link – Top iOS Interview Questions You Must Prepare In 2018

Panel:

Panel: Fortæl mig venligst design for et elevatorsystem.

Du: Følg nedenstående fremgangsmåde for at identificere, om panelet er interesseret i klassedesign og dets relation eller interesseret i backend, som det ser ud Dette er et ret bredt spørgsmål.

Fra applikationsudviklerens perspektiv bør vi fortælle klasserne og deres relation, klassediagrammer & Sequence flow. Vi kender alle tidsmangel under en teknisk diskussion, og nogle gange er det svært, hvad den anden fyr forventer af os.

I et generelt perspektiv kan det være muligt, at dit panel er interesseret i backend-design, så du skal afklare med ham, hvad forventer de af dig?

Et øjebliksbillede af elevatorstyringssystemet

Vores elevator har den grundlæggende funktion, som alle elevatorsystemer har, såsom at bevæge sig op og ned, åbne og lukke døre og selvfølgelig samle passagerer op.

Hevnen skal bruges i en bygning, der har etager nummereret fra 1 til MaxFloor, hvor første etage er lobbyen. Der er kupe(elevator)opkaldsknapper i kupeen svarende til hver etage. For hver etage med undtagelse af øverste etage og lobbyen er der to hallopkaldsknapper, som passagererne kan kalde for at gå op og ned. Der er kun en knap til at kalde nedad på øverste etage og en knap til at kalde opad i lobbyen. Når vognen standser på en etage, åbnes dørene, og vognlanternen, der angiver den aktuelle retning, som vognen kører, tændes, så passagererne kan få kendskab til vognens aktuelle kørselsretning. Bilen kører hurtigt mellem etagerne, men den skal være i stand til at sætte farten ned i god tid, så den kan standse på en ønsket etage. For at certificere systemets sikkerhed vil nødbremsen blive udløst, og bilen vil blive tvunget til at standse under alle usikre forhold.

Alle systemer interagerer med menneskelige eller automatiserede aktører, der bruger systemet til et eller andet formål, og både mennesker og aktører forventer, at systemet opfører sig på en forudsigelig måde.

Der er syv brugssager baseret på elevatorsystemets nuværende krav, som vist i figur 1:

• Behandling af kasse-/elevatoropkald: Denne use case omfatter flere scenarier, som vil blive beskrevet i detaljer i senere afsnit i dette dokument. Disse scenarier omfatter, at elevatoren modtager elevator-/car call-opkald fra passagererne, tænder eller slukker lyset på elevator-/car call-knapperne, opdaterer den registrering af elevator-/car call-opkald, der er gemt i systemets styringsdele osv.
• Process Hall Calls: I lighed med behandling af elevator-/bilopkald omfatter denne brugssituation, at elevatoren modtager hallopkald fra passagererne, tænder eller slukker lyset på hallopkaldsknapperne, opdaterer registreringen af hallopkald i systemstyringsdelene osv.
• Flyt/stopper bilen: Elevatorens hovedfunktion omfatter ændring af kørselshastighed, hvordan man træffer beslutning om stop, og kørselsretninger for elevatoren.
• Angivelse af kørselsretning: Elevatoren skal have denne mekanisme for at lade passagererne vide, hvilken kørselsretning elevatoren har, så passageren kan beslutte, om han/hun vil gå ind i elevatorstolen eller ej.
• Angivelse af elevatorens position: På samme måde bør elevatoren lade passagererne vide, om deres bestemmelsesetage er nået, så de kan beslutte at forlade elevatorstolen.
• Åbn/luk dørene: Elevatoren skal kunne åbne og lukke dørene, så passagererne kan komme ind og ud af elevatorstolen. Funktionsområderne i denne use case bør også gøre det muligt for passagererne at foretage døromvendinger, når dørene lukkes, og passageren ønsker at komme ind i elevatorstolen.
• Udløsning af nødbremse: Med denne store forståelse af elevatorsystemet kan vi begynde at identificere de klasser, der er nødvendige for at designe et system.
  

  Identificering af klasser/objekter:

  • ElevatorControl: ElevatorControl: Der er en sikkerhedsmekanisme i bilen for at sikre, at en usikker tilstand ikke genereres midlertidigt.

  Det centrale styringsobjekt i elevatorsystemet. ElevatorControl kommunikerer og styrer alle andre objekter i systemet.

• Dør: ElevatorControl: ElevatorControl: Der er to døre i systemet, og “gud”-objektet – ElevatorControl – giver ordre til at åbne og lukke dørene.
• Bil/elevator: Bilen styres til at køre op og ned (i forskellige hastigheder) og til at standse på etager, når det er nødvendigt.
• Knap: ElevatorControl-klassen styrer også knappen-klassen, som yderligere generaliserer to underklasser CarCallButton og HallCallButton. Kontrolobjektet kommunikerer med Button-objekterne, får oplysninger om, hvorvidt der er trykket på en knap, og styrer til gengæld belysningen af knaplysene.
• Indikator: Der er to slags indikatorer i systemet, CarPositionIndicator og CarDirectionIndicator (dvs. CarLantern). Indikatorerne styres for at vise oplysninger om bilens aktuelle position og kørselsretning.
• Sikkerhed: Når der opstår en nødsituation, kommanderer ElevatorControl Safety

Controller-klasserne:

• DoorControl styrer DoorMotor’s handling. DoorMotor kan kommanderes til at åbne, lukke eller foretage en dørvending.
• DriveControl styrer elevatorens drev, der fungerer som hovedmotor, der bevæger elevatorkabinen op og ned og stopper på etager, når det er nødvendigt.
• LanternControl er i antallet af to, CarPositionIndicator og CarDirectionIndicator.
• HallButtonControl findes i par på hver etage, hvor den ene styrer den opadgående HallCallButton og den anden den nedadgående. HallButtonControl accepterer kontrolelementer for tryk på hallopkaldsknapper samt giver feedback til hallopkaldslamper.
• CarButtonControl findes én for hver etage og alle er placeret i elevatoren/kabinen. CarButtonControl accepterer CarCallButton-opkald og er ansvarlig for at tænde/slukke de tilsvarende opkaldslamper i elevatoren/kabinen.
• CarPositionIndicator giver værdi til CarPositionIndicator, så passagererne kan kende elevatorens/kabinens aktuelle position.
• Dispatcher styrer ikke de faktiske elevatorkomponenter, men er vigtig i softwaresystemet. Der er en Dispatcher for hver elevator/kabine, hvis hovedfunktion er at beregne målbevægelsesretningen og destinationen for elevatoren/kabinen samt at opretholde åbningstiden for dørene. Dispatcher interagerer med næsten alle kontrolobjekter i systemet undtagen LanternControl.

Håber alt går godt indtil nu, lad os forstå det hele med nogle af sekvensdiagrammerne.

Sekvensflow

Det kan være svært at forklare mundtligt, men hvis du klart forstår, hvordan det kommer til at fungere, kan du tegne nogle sekvensdiagrammer og forsøge at forklare flowet med nogle eksempler parallelt.

1. Process hall calls : Der er to scenarier for denne use case:
   1.1 elevatoren bevæger sig i samme retning som passagerens destination.
   1.2 elevatoren bevæger sig i den modsatte retning som passagerens destination.

2. Flytning/stop af bilen:

3. Angivelse af kørselsretning:

4. Udløsning af nødbremse : Der er fem scenarier for denne use case:

1. Hvis bilen kommanderes til at standse, men den vil ikke standse ved et ønsket gulv, udløses nødbremsen.

2. Hvis bilen kommanderes til at bevæge sig, men den bevæger sig ikke, udløses nødbremsen.

3. Hvis dørene kommanderes til at åbne, når bilen standser på en etage, men dørene ikke åbnes, udløses nødbremsen.

4. Hvis dørene åbnes, når bilen er i bevægelse, udløses nødbremsen.

5. Hvis bilen fortsætter med at køre, når hejsevejsgrænsen er nået, udløses nødbremsen.

Jeg vil kun vise ét sekvensdiagram for tilfælde 5.

Jeg forventer, at de fleste af tingene vil blive billede i dit hoved og let at huske samt at forklare. For backend design , følg venligst System Design serien

Håber du kan lide forklaringen. For flere designspørgsmål , Vent venligst og følg mig.