LLD o progettazione di basso livello è un processo di progettazione a livello di componente che segue il processo di perfezionamento passo dopo passo. L'input per LLD è HLD.

Cos'è il Low Level Design o LLDn

Argomenti importanti per la progettazione di basso livello (LLD)

• Che cos'è la progettazione di basso livello (LLD)?
• In che modo l'LLD è diverso dall'HLD?
• Come formare LLD da HLD?
• Roadmap verso la progettazione di basso livello

Che cos'è la progettazione di basso livello (LLD)?

LLD, o Low-Level Design, è una fase del processo di sviluppo del software in cui vengono specificati i componenti dettagliati del sistema e le loro interazioni. Implica la conversione della progettazione di alto livello in un progetto più dettagliato, affrontando algoritmi, strutture dati e interfacce specifici. LLD funge da guida per gli sviluppatori durante la codifica, garantendo l'implementazione accurata ed efficiente delle funzionalità del sistema. LLD descrive i diagrammi delle classi con l'aiuto di metodi e relazioni tra classi e specifiche del programma.

elenco comparabile

Ricordare: La progettazione di basso livello è anche nota come progettazione a livello di oggetto O livello micro O progettazione dettagliata .

Diagramma delle classi in LLD

In questo diagramma elenchiamo sostanzialmente tutte le entità che possono far parte dei componenti. I diagrammi delle classi vengono realizzati man mano che diventa più semplice per lo sviluppatore convertirli in codice.

Ad esempio:

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

In che modo l'LLD è diverso dall'HLD?

Come studiato, Design di alto livello o HLD è una progettazione generale del sistema in cui effettuiamo compromessi tra diversi framework, componenti e diversi database e scegliamo il migliore considerando ciò di cui l'azienda ha bisogno e come dovrebbe funzionare il sistema, sia in termini di aspetti funzionali che non funzionali. Qui definiamo i componenti e il modo in cui questi componenti comunicheranno tra loro. Quindi qui ci preoccupiamo di cose generiche come segue e non ci preoccupiamo del codice.

1. Selezione di componenti, piattaforme e diversi strumenti.
2. Progettazione di banche dati.
3. Breve descrizione delle relazioni tra servizi e moduli.

Come formare LLD da HLD?

Come studiato in precedenza, l'input per l'inquadramento della progettazione di basso livello (LLD) è l'HLD. Qui in LLD, ci prendiamo cura di come appariranno i nostri componenti, della struttura posseduta dalle diverse entità e di come le diverse entità avranno le loro responsabilità (operazioni supportate). Per questa conversione, utilizziamo Diagrammi UML (Unified Modeling Language). . In aggiunta a questi diagrammi usiamo Principi OOPS E Principi SOLIDI durante la progettazione. Quindi, utilizzando questi 3 paradigmi possiamo convertire qualsiasi HLD in LLD in modo da essere implementato.

Roadmap verso la progettazione di basso livello

Per collegare i concetti di LLD con il codice reale, per capire come progettare qualsiasi diagramma di basso livello, cerchiamo di capire attraverso i passaggi:

java tostring

1. Principi orientati agli oggetti

Il requisito dell'utente viene elaborato utilizzando i concetti di programmazione OOPS. Pertanto si consiglia di acquisire una solida conoscenza dei concetti OOPS prima di procedere nella progettazione di qualsiasi sistema di basso livello. Il concetto di programmazione orientata agli oggetti 4 pilastri sono indispensabili per iniziare ad apprendere la progettazione di basso livello e il programmatore dovrebbe essere molto esperto di questi 4 pilastri, ovvero come segue:

1. Eredità
2. incapsulamento
3. polimorfismo
4. astrazione

All'interno del polimorfismo, dovremmo essere chiari con il polimorfismo in fase di compilazione e in fase di esecuzione. I programmatori dovrebbero essere assolutamente chiari sui concetti OOPS da approfondire fino alle classi e agli oggetti perché OOPS è il fondamento su cui si basa il basso livello su qualsiasi sistema. La progettazione di basso livello è 'estremamente soggettiva' perché dobbiamo utilizzare questi concetti in modo ottimale durante la codifica per costruire un sistema di basso livello implementando entità software di codifica (classi, funzioni, moduli, ecc.)

2. Processo di analisi e progettazione

È una fase di analisi che è il nostro primo passo in cui trasformiamo i problemi del mondo reale in problemi del mondo degli oggetti utilizzando concetti OOPS e principi SOLID.

3. Modelli di progettazione

Ora l'implementazione del nostro problema orientato agli oggetti di cui sopra viene eseguita con l'aiuto di modelli di progettazione. I modelli di progettazione sono soluzioni riutilizzabili ai problemi comuni riscontrati nella progettazione del software. Forniscono un approccio strutturato alla progettazione acquisendo le migliori pratiche e soluzioni comprovate, facilitando lo sviluppo di software scalabile, manutenibile ed efficiente. I modelli di progettazione aiutano a semplificare il processo di sviluppo, promuovono il riutilizzo del codice e migliorano la qualità complessiva dei sistemi software.

Ogni modello descrive un problema che si verifica ripetutamente più volte nell'ambiente e le relative soluzioni possono essere applicate ripetutamente senza ridondanza.

Perché sono necessari modelli di progettazione?

Questi problemi si sono verificati più e più volte in corrispondenza delle quali sono state presentate queste soluzioni. Questi problemi sono stati affrontati e risolti da progettisti esperti nel mondo della programmazione e le soluzioni sono robuste nel tempo risparmiando molto tempo ed energie. Quindi i problemi classici e complessi del mondo del software vengono risolti con soluzioni provate e testate.

Mancia: Si consiglia vivamente di avere una buona conoscenza dei modelli di progettazione comuni per avere una buona padronanza della progettazione di basso livello.

Diversi tipi di modelli di progettazione

Esistono molti tipi di modelli di progettazione, parliamo di 4 tipi di modelli di progettazione ampiamente utilizzati a livello globale:

• Modello di progettazione di fabbrica
• Modello astratto di fabbrica
• Modello Singleton
• Modello dell'osservatore

Si consiglia inoltre di studiare i 5 modelli di progettazione riportati di seguito poiché sono meno richiesti, ma si consiglia di studiarli per una comprensione di base dei modelli di progettazione.

• Modello del costruttore
• Modello di catena di responsabilità
• Modello adattatore
• Modello di facciata
• Modello peso mosca

4. Diagramma UML

Ci sono 2 tipi di diagrammi UML:

programma Java

1. Diagramma strutturale UML: Questi tipi di diagrammi definiscono fondamentalmente come saranno strutturate le diverse entità e oggetti e definiscono la relazione tra loro. Sono utili per rappresentare come appariranno i componenti rispetto alla struttura.
2. Diagramma UML comportamentale: Questi tipi di diagrammi definiscono sostanzialmente quali sono le diverse operazioni che supporta. Qui diversi UML comportamentali mostrano comportamenti diversi

Mancia: I diagrammi UML importanti utilizzati frequentemente dagli sviluppatori sono i seguenti:

• Diagramma delle classi da Diagramma UML strutturale
• Sequenza , Caso d'uso E Attività dal diagramma UML comportamentale.

5. Principi SOLIDI

Si tratta di insiemi di 5 principi (regole) che vengono rigorosamente seguiti in base ai requisiti del sistema o ai requisiti per una progettazione ottimale.

Per scrivere codice scalabile, flessibile, manutenibile e riutilizzabile:

1. Principio di responsabilità unica (SRP)
2. Principio aperto-chiuso (OCP)
3. Principio di sostituzione di Liskov (LSP)
4. Principio di segregazione dell'interfaccia (ISP)
5. Principio di inversione delle dipendenze (DIP)

È importante tenere presente che i principi SOLIDI sono solo linee guida e non regole rigide da seguire. La chiave è trovare un equilibrio tra l'adesione a questi principi e la considerazione delle esigenze e dei vincoli specifici delle esigenze aziendali.