LLD eller lavnivådesign er en designprosess på komponentnivå som følger trinnvis foredlingsprosess. Inngangen til LLD er HLD.

Hva er lavnivådesign eller LLDn

Viktige emner for lavnivådesign (LLD)

• Hva er lavnivådesign (LLD)?
• Hvordan er LLD forskjellig fra HLD
• Hvordan danne LLD fra HLD?
• Veikart til design på lavt nivå

Hva er lavnivådesign (LLD)?

LLD, eller Low-Level Design, er en fase i programvareutviklingsprosessen hvor detaljerte systemkomponenter og deres interaksjoner er spesifisert. Det innebærer å konvertere høynivådesignet til en mer detaljert plan, adressering spesifikke algoritmer, datastrukturer og grensesnitt. LLD fungerer som en guide for utviklere under koding, og sikrer nøyaktig og effektiv implementering av systemets funksjonalitet. LLD beskriver klassediagrammer ved hjelp av metoder og relasjoner mellom klasser og programspesifikasjoner.

Huske: Design på lavt nivå er også kjent som design på objektnivå eller mikronivå eller detaljert design .

Klassediagram i LLD

I dette diagrammet lister vi i utgangspunktet opp alle enhetene som kan være en del av komponenter. Klassediagrammer lages ettersom det blir lettere for utviklere å konvertere det til kode.

For eksempel:

User Service  <-- User   <--Profile  <--ID>

Hvordan er LLD forskjellig fra HLD

Som studert, High Level Design eller HLD er et generelt systemdesign hvor vi gjør avveininger mellom ulike rammeverk, komponenter og ulike databaser og vi velger det beste med tanke på hva virksomheten trenger og hvordan systemet skal fungere, både når det gjelder funksjonelle og ikke-funksjonelle aspekter. Her definerer vi komponentene og hvordan disse komponentene skal kommunisere med hverandre. Derfor er vi her plaget med generiske ting som følger og ikke plaget med koden.

java hvis annet

1. Valg av komponenter, plattformer og ulike verktøy.
2. Database design.
3. Kort beskrivelse av sammenhenger mellom tjenester og moduler.

Hvordan danne LLD fra HLD?

Som studert ovenfor, er input for framing low-level design (LLD) HLD. Her i LLD tar vi vare på hvordan komponentene våre vil se ut, strukturen som besittes av ulike enheter, og hvordan ulike enheter vil ha sitt ansvar (operasjoner støttet). For denne konverteringen bruker vi Unified Modeling Language (UML) diagrammer . Legger til disse diagrammene vi bruker OOPS-prinsipper og SOLIDE prinsipper mens du designer. Derfor, ved å bruke disse 3 paradigme, kan vi konvertere enhver HLD til LLD for å bli implementert.

Veikart til design på lavt nivå

For å bygge bro mellom konsepter av LLD med ekte kode, la oss For å forstå hvordan vi utformer et hvilket som helst lavnivådiagram la oss forstå via trinnene:

1. Objektorienterte prinsipper

Brukerkravet behandles ved å bruke konsepter for OOPS-programmering. Derfor anbefales det å ha et sterkt grep om OOPS-konsepter før du går videre med utformingen av et lavnivåsystem. Objektorientert programmeringskonsept 4 pilarer er et must for å begynne å lære design på lavt nivå, og programmereren bør være godt kjent med disse 4 pilarene, nemlig som følger:

1. Arv
2. innkapsling
3. polymorfisme
4. abstraksjon

Innen polymorfisme bør vi være tydelige med kompileringstids- og kjøretidspolymorfisme. Programmerere bør være helt tydelige på OOPS-konseptene til dybden rett til klasser og objekter fordi OOPS er grunnlaget som lav-nivellering på ethvert system er basert på. Å oppnå lavnivådesign er 'ekstremt subjektivt' fordi vi må optimalt bruke disse konseptene mens vi koder for å bygge et lavnivåsystem via implementering av kodingsprogramvareenheter (klasser, funksjoner, moduler osv.)

2. Prosess for analyse og design

Det er en analyserende fase som er vårt første trinn der vi kler virkelige problemer til objektverden problemer ved å bruke OOPS-konsepter og SOLID-prinsipper.

3. Design mønstre

Nå utføres implementeringen av vårt objektorienterte problem ovenfor ved hjelp av designmønstre. Designmønstre er gjenbrukbare løsninger på vanlige problemer som oppstår i programvaredesign. De gir en strukturert tilnærming til design ved å fange opp beste praksis og utprøvde løsninger, noe som gjør det enklere å utvikle skalerbar, vedlikeholdbar og effektiv programvare. Designmønstre bidrar til å strømlinjeforme utviklingsprosessen, fremme gjenbruk av kode og forbedre den generelle kvaliteten på programvaresystemer.

Hvert mønster beskriver et problem som oppstår om og om igjen flere ganger i miljøet, og deres løsninger kan brukes gjentatte ganger uten redundans.

Hvorfor er det behov for designmønstre?

Disse problemene har oppstått om og om igjen tilsvarende som disse løsningene har blitt lagt ut. Disse problemene har blitt møtt og løst av ekspertdesignere i programmeringsverdenen, og løsningene er robuste over tid og sparer mye tid og energi. Derfor blir de komplekse og klassiske problemene i programvareverdenen løst av utprøvde løsninger.

vårm

Tips: Det anbefales på det sterkeste å ha god forståelse for vanlige designmønstre for å ha et godt grep over design på lavt nivå.

Ulike typer designmønstre

Det er vidt mange typer designmønstre, la oss diskutere 4 typer designmønstre som er mye brukt globalt:

• Fabrikkdesignmønster
• Abstrakt fabrikkmønster
• Singleton mønster
• Observatørmønster

Det anbefales også å studere de 5 designmønstrene nedenfor, da disse er mindre nødvendige, men det anbefales å lære for den grunnleggende forståelsen av designmønstrene.

• Bygger mønster
• Ansvarskjedemønster
• Adaptermønster
• Fasade mønster
• Fluevekt mønster

4. UML diagram

Det er 2 typer UML-diagrammer:

java-program

1. Strukturelt UML-diagram: Disse typer diagrammer definerer i utgangspunktet hvordan ulike enheter og objekter skal struktureres og definerer forholdet mellom dem. De er nyttige for å representere hvordan komponenter vil se ut med hensyn til struktur.
2. Atferdsmessig UML-diagram: Disse typer diagrammer definerer i utgangspunktet hva som er de forskjellige operasjonene som den støtter. Her viser ulike atferdsmessige UML ulike atferdsmessige av

Tips: Viktige UML-diagrammer som ofte brukes av utviklere er som følger:

• Klassediagram fra Strukturelt UML-diagram
• Sekvens , Bruk case og Aktivitet fra Behavioral UML Diagram.

5. SOLIDE prinsipper

Dette er sett med 5 prinsipper (regler) som følges strengt i henhold til kravene til systemet eller kravene for optimal design.

For å skrive skalerbar, fleksibel, vedlikeholdbar og gjenbrukbar kode:

1. Enkeltansvarsprinsipp (SRP)
2. Åpent lukket prinsipp (OCP)
3. Liskovs erstatningsprinsipp (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

Det er viktig å huske på at SOLIDE prinsipper bare er retningslinjer og ikke strenge regler som skal følges. Nøkkelen er å finne en balanse mellom å følge disse prinsippene og å vurdere de spesifikke behovene og begrensningene til bedriftens krav.