LLD oder Low-Level-Design ist ein Entwurfsprozess auf Komponentenebene, der einem schrittweisen Verfeinerungsprozess folgt. Die Eingabe für LLD ist HLD.

Was ist Low Level Design oder LLDn?

Wichtige Themen für das Low Level Design (LLD)

• Was ist Low-Level-Design (LLD)?
• Wie unterscheidet sich LLD von HLD?
• Wie bildet man LLD aus HLD?
• Roadmap zum Low-Level-Design

Was ist Low-Level-Design (LLD)?

LLD oder Low-Level-Design ist eine Phase im Softwareentwicklungsprozess, in der detaillierte Systemkomponenten und ihre Interaktionen spezifiziert werden. Dabei geht es um die Umwandlung des High-Level-Designs in einen detaillierteren Entwurf, der sich mit spezifischen Algorithmen, Datenstrukturen und Schnittstellen befasst. LLD dient Entwicklern als Leitfaden während der Codierung und stellt die genaue und effiziente Implementierung der Systemfunktionen sicher. LLD beschreibt Klassendiagramme mithilfe von Methoden und Beziehungen zwischen Klassen und Programmspezifikationen.

Erinnern: Low-Level-Design wird auch als Low-Level-Design bezeichnet Design auf Objektebene oder Mikroebene oder detaillierte Gestaltung .

Klassendiagramm in LLD

In diesem Diagramm listen wir grundsätzlich alle Entitäten auf, die Teil von Komponenten sein können. Klassendiagramme werden erstellt, da es für Entwickler einfacher wird, sie in Code umzuwandeln.

partielle Latexableitung

Zum Beispiel:

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

Wie unterscheidet sich LLD von HLD?

Wie untersucht, High Level Design oder HLD ist ein allgemeiner Systementwurf, bei dem wir Kompromisse zwischen verschiedenen Frameworks, Komponenten und verschiedenen Datenbanken eingehen und unter Berücksichtigung der Geschäftsanforderungen und der Funktionsweise des Systems das Beste auswählen, sowohl im Hinblick auf funktionale als auch nicht funktionale Aspekte. Hier definieren wir die Komponenten und wie diese Komponenten miteinander kommunizieren. Daher beschäftigen wir uns hier mit generischen Dingen wie den folgenden und nicht mit dem Code.

Konvertieren Sie einen String in einen Int

1. Auswahl von Komponenten, Plattformen und verschiedenen Werkzeugen.
2. Datenbank Design.
3. Kurze Beschreibung der Beziehungen zwischen Diensten und Modulen.

Wie bildet man LLD aus HLD?

Wie oben untersucht, ist HLD die Eingabe für das Framing von Low-Level-Design (LLD). Hier bei LLD kümmern wir uns darum, wie unsere Komponenten aussehen, welche Struktur die verschiedenen Einheiten haben und wie verschiedene Einheiten ihre Verantwortung haben (unterstützte Abläufe). Für diese Konvertierung verwenden wir UML-Diagramme (Unified Modeling Language). . Ergänzend zu diesen Diagrammen verwenden wir OOPS-Prinzipien Und SOLIDE Prinzipien beim Entwerfen. Mit diesen drei Paradigmen können wir daher jedes HLD in LLD umwandeln, um es umzusetzen.

Roadmap zum Low-Level-Design

Um LLD-Konzepte mit echtem Code zu verbinden, lassen Sie uns die folgenden Schritte ausführen, um zu verstehen, wie ein Low-Level-Diagramm entworfen wird:

1. Objektorientierte Prinzipien

Die Benutzeranforderung wird mithilfe von Konzepten der OOPS-Programmierung verarbeitet. Daher wird empfohlen, sich mit den OOPS-Konzepten vertraut zu machen, bevor man mit dem Entwurf eines Low-Level-Systems fortfährt. Die 4 Säulen des objektorientierten Programmierkonzepts sind ein Muss, um mit dem Erlernen des Low-Level-Designs zu beginnen, und der Programmierer sollte mit diesen 4 Säulen sehr gut vertraut sein, und zwar wie folgt:

1. Nachlass
2. Verkapselung
3. Polymorphismus
4. Abstraktion

Innerhalb des Polymorphismus sollten wir uns hinsichtlich des Kompilierzeit- und Laufzeitpolymorphismus klar im Klaren sein. Programmierer sollten sich über die OOPS-Konzepte bis hin zu Klassen und Objekten absolut im Klaren sein, denn OOPS ist die Grundlage, auf der Low-Leveling auf jedem System basiert. Die Umsetzung eines Low-Level-Designs ist „extrem subjektiv“, da wir diese Konzepte beim Codieren optimal nutzen müssen, um durch die Implementierung von Codierungs-Softwareeinheiten (Klassen, Funktionen, Module usw.) ein Low-Level-System aufzubauen.

2. Analyse- und Designprozess

Es handelt sich um eine Analysephase, die unser erster Schritt ist, in der wir reale Probleme mithilfe von OOPS-Konzepten und SOLID-Prinzipien in Probleme der Objektwelt umwandeln.

3. Designmuster

Nun erfolgt die Umsetzung unseres oben genannten objektorientierten Problems mit Hilfe von Entwurfsmustern. Entwurfsmuster sind wiederverwendbare Lösungen für häufige Probleme beim Softwaredesign. Sie bieten einen strukturierten Entwurfsansatz, indem sie Best Practices und bewährte Lösungen erfassen und so die Entwicklung skalierbarer, wartbarer und effizienter Software erleichtern. Entwurfsmuster tragen dazu bei, den Entwicklungsprozess zu rationalisieren, die Wiederverwendung von Code zu fördern und die Gesamtqualität von Softwaresystemen zu verbessern.

Jedes Muster beschreibt ein Problem, das in der Umgebung immer wieder auftritt, und seine Lösungen können ohne Redundanz wiederholt angewendet werden.

Warum besteht ein Bedarf an Designmustern?

Java-Programm

Diese Probleme sind immer wieder aufgetreten und entsprechend wurden diese Lösungen dargelegt. Diese Probleme werden von erfahrenen Designern in der Programmierwelt angegangen und gelöst, und die Lösungen sind im Laufe der Zeit robust und sparen viel Zeit und Energie. Somit werden die komplexen und klassischen Probleme in der Softwarewelt durch bewährte Lösungen gelöst.

Tipp: Es wird dringend empfohlen, über ein gutes Verständnis gängiger Entwurfsmuster zu verfügen, um einen guten Überblick über das Design auf niedriger Ebene zu haben.

Verschiedene Arten von Designmustern

Es gibt sehr viele Arten von Entwurfsmustern. Lassen Sie uns vier Arten von Entwurfsmustern besprechen, die weltweit häufig verwendet werden:

• Fabrikdesignmuster
• Abstraktes Fabrikmuster
• Singleton-Muster
• Beobachtermuster

Es wird außerdem empfohlen, die folgenden 5 Entwurfsmuster zu studieren, da diese weniger erforderlich sind, es wird jedoch empfohlen, sie zu erlernen, um ein grundlegendes Verständnis der Entwurfsmuster zu erlangen.

• Builder-Muster
• Muster der Verantwortungskette
• Adaptermuster
• Fassadenmuster
• Fliegengewichtsmuster

4. UML Diagram

Es gibt zwei Arten von UML-Diagrammen:

Pseudocode Java

1. Strukturelles UML-Diagramm: Diese Art von Diagrammen definiert im Wesentlichen, wie verschiedene Entitäten und Objekte strukturiert werden und welche Beziehungen zwischen ihnen bestehen. Sie sind hilfreich bei der Darstellung, wie Komponenten in Bezug auf die Struktur aussehen.
2. Verhaltens-UML-Diagramm: Diese Art von Diagrammen definiert im Wesentlichen die verschiedenen Vorgänge, die unterstützt werden. Hier zeigt UML unterschiedliche Verhaltensweisen von unterschiedlichen Verhaltensweisen

Tipp: Wichtige UML-Diagramme, die von Entwicklern häufig verwendet werden, sind wie folgt:

• Klassen Diagramm aus Strukturelles UML-Diagramm
• Reihenfolge , Anwendungsfall Und Aktivität aus dem Verhaltens-UML-Diagramm.

5. SOLIDE Prinzipien

Hierbei handelt es sich um Sätze von fünf Prinzipien (Regeln), die gemäß den Anforderungen des Systems oder den Anforderungen für ein optimales Design strikt befolgt werden.

Um skalierbaren, flexiblen, wartbaren und wiederverwendbaren Code zu schreiben:

1. Einverantwortungsprinzip (SRP)
2. Offen-Geschlossen-Prinzip (OCP)
3. Liskovs Substitutionsprinzip (LSP)
4. Prinzip der Schnittstellentrennung (ISP)
5. Abhängigkeitsinversionsprinzip (DIP)

Es ist wichtig zu bedenken, dass die SOLID-Prinzipien lediglich Richtlinien und keine strengen Regeln sind, die befolgt werden müssen. Der Schlüssel liegt darin, ein Gleichgewicht zwischen der Einhaltung dieser Grundsätze und der Berücksichtigung der spezifischen Bedürfnisse und Einschränkungen Ihrer Geschäftsanforderungen zu finden.