Connect with us

Entwicklung & Code

Künstliche Neuronale Netze im Überblick 11: Implementierung eines Transformers


Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der elfte und letzte Teil implementiert einen Transformer.


Michael Stal

Michael Stal

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.

Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Der Transformer ist eine neuronale Architektur, die vollständig auf Aufmerksamkeitsmechanismen basiert und ohne Rekursion und Faltung auskommt, um Sequenzen parallel zu verarbeiten. Seine wichtigste Innovation ist die skalierte Skalarprodukt-Attention-Unterschicht, die gleichzeitig die Beziehungen zwischen allen Positionen in der Eingabe berechnet. Ein Transformer-Encoder stapelt mehrere Schichten von Multi-Head-Self-Attention- und positionsbezogenen Feed-Forward-Netzwerken, die jeweils in Restverbindungen und Schichtnormalisierung eingebettet sind. Der Decoder fügt maskierte Selbstaufmerksamkeit und Encoder-Decoder-Aufmerksamkeit hinzu, um eine autoregressive Generierung zu ermöglichen.

Wir beginnen mit der Formalisierung der skalierten Skalarprodukt-Aufmerksamkeit. Bei gegebenen Abfrage-, Schlüssel- und Wertematrizen Q, K und V mit den Formen (batch_size, num_heads, seq_len, d_k) berechnen wir Rohwerte, indem wir das Punktprodukt von Q mit der Transponierten von K bilden. Anschließend skalieren wir diese Werte mit √d_k, um zu verhindern, dass Extremwerte zu verschwindenden Gradienten führen, wenden Softmax an, um Aufmerksamkeitsgewichte zu erhalten, und multiplizieren mit V, um die beachtete Ausgabe zu erhalten:

Attention(Q, K, V) = softmax( (Q · Kᵀ) / √d_k ) · V

In PyTorch lässt sich die wie folgt umsetzen:


import torch
import torch.nn.functional as F

def scaled_dot_product_attention(Q, K, V, mask=None):
    """
    Berechnet die skalierte Skalarprodukt-Aufmerksamkeit.
    
    Q, K, V haben die Form (batch_size, num_heads, seq_len, d_k).
    Mask, falls angegeben, wird zu den Bewertungen hinzugefügt, um die Aufmerksamkeit auf bestimmte Positionen zu verhindern.
    """
    d_k = Q.size(-1)
    # Berechne die rohen Aufmerksamkeitswerte.
    scores = torch.matmul(Q, K.transpose(-2, -1)) / torch.sqrt(torch.tensor(d_k, dtype=torch.float32))
    # Wende die Maske an (z. B. um zu verhindern, dass nachfolgende Token im Decoder Beachtung finden).
    if mask is not None:
        scores = scores + mask
    # Normalisieren, um Aufmerksamkeitsgewichte zu erhalten.
    attn_weights = F.softmax(scores, dim=-1)
    # Berechne die gewichtete Summe der Werte.
    output = torch.matmul(attn_weights, V)
    return output, attn_weights


In dieser Funktion extrahieren wir die Dimension d_k aus Q, berechnen die Skalarprodukte, skalieren sie und fügen optional vor dem Softmax eine Maske hinzu. Die Maske enthält große negative Werte (−∞) an unzulässigen Positionen, sodass diese Positionen nach dem Softmax das Gewicht Null erhalten.

Multi-Head-Attention erweitert diesen Ansatz, indem es dem Modell ermöglicht, Informationen aus mehreren Darstellungsunterräumen gemeinsam zu berücksichtigen. Zunächst projizieren wir den Eingabetensor X der Form (batch_size, seq_len, d_model) mithilfe gelernter linearer Schichten auf Abfragen, Schlüssel und Werte. Anschließend teilen wir jede dieser Projektionen entlang der Merkmalsdimension in num_heads separate Köpfe auf, wenden die Skalarprodukt-Aufmerksamkeit parallel auf jeden Kopf an, verknüpfen die Ergebnisse und projizieren sie zurück auf das ursprüngliche d_model:


import torch
import torch.nn as nn

class MultiHeadAttention(nn.Module):
    def __init__(self, d_model, num_heads):
        super(MultiHeadAttention, self).__init__()
        assert d_model % num_heads == 0, "d_model muss durch num_heads teilbar sein"
        self.num_heads = num_heads
        self.d_k = d_model // num_heads
        # Lineare Projektionen für Abfragen, Schlüssel, Werte und die endgültige Ausgabe.
        self.W_q = nn.Linear(d_model, d_model)
        self.W_k = nn.Linear(d_model, d_model)
        self.W_v = nn.Linear(d_model, d_model)
        self.W_o = nn.Linear(d_model, d_model)

    def forward(self, X, mask=None):
        batch_size, seq_len, _ = X.size()
        # Projektionen der Eingaben auf Q, K, V.
        Q = self.W_q(X)
        K = self.W_k(X)
        V = self.W_v(X)
        # Umformen und transponieren, um Köpfe zu trennen.
        Q = Q.view(batch_size, seq_len, self.num_heads, self.d_k).transpose(1, 2)
        K = K.view(batch_size, seq_len, self.num_heads, self.d_k).transpose(1, 2)
        V = V.view(batch_size, seq_len, self.num_heads, self.d_k).transpose(1, 2)
        # Skalarprodukt-Aufmerksamkeit anwenden.
        attn_output, _ = scaled_dot_product_attention(Q, K, V, mask)
        # Köpfe verknüpfen und zurück auf d_model projizieren.
        concat = attn_output.transpose(1, 2).contiguous().view(batch_size, seq_len, -1)
        output = self.W_o(concat)
        return output


Da der Transformer keine integrierte Vorstellung von Reihenfolge hat, werden den Token-Einbettungen Positionscodierungen hinzugefügt, um dem Modell Informationen über die Position jedes Elements in der Sequenz zu liefern. Der ursprüngliche Transformer verwendet sinusförmige Codierungen, die wie folgt definiert sind:

P[pos, 2i ] = sin( pos / (10000^(2i/d_model)) )

P[pos, 2i+1 ] = cos( pos / (10000^(2i/d_model)) )

für pos in [0, L−1] und i in [0, d_model/2−1].

Wir implementieren dies wie folgt:


import torch
import math

def get_sinusoidal_positional_encoding(L, d_model):
    # Erstelle einen Tensor der Form (L, d_model).
    P = torch.zeros(L, d_model)
    position = torch.arange(0, L).unsqueeze(1).float()
    div_term = torch.exp(torch.arange(0, d_model, 2).float() * -(math.log(10000.0) / d_model))
    # Sinus auf gerade Indizes anwenden
    P[:, 0::2] = torch.sin(position * div_term)
    # Cosinus auf ungerade Indizes anwenden.
    P[:, 1::2] = torch.cos(position * div_term)
    return P


Jede Encoder-Schicht besteht aus einer Selbstaufmerksamkeits-Unterschicht, gefolgt von einem positionsbezogenen Feedforward-Netzwerk. Beide Unterschichten sind in Restverbindungen eingeschlossen. Darauf folgen eine Schichtnormalisierung und ein Dropout. Das Feedforward-Netzwerk hat die Form:

FFN(x) = ReLU(x·W₁ + b₁)·W₂ + b₂

und wird unabhängig auf jede Position angewendet. Wir erstellen eine Encoder-Schicht in PyTorch:


class TransformerEncoderLayer(nn.Module):
    def __init__(self, d_model, num_heads, d_ff, dropout=0.1):
        super(TransformerEncoderLayer, self).__init__()
        self.self_attn = MultiHeadAttention(d_model, num_heads)
        self.ffn = nn.Sequential(
            nn.Linear(d_model, d_ff),
            nn.ReLU(),
            nn.Linear(d_ff, d_model),
        )
        self.norm1 = nn.LayerNorm(d_model)
        self.norm2 = nn.LayerNorm(d_model)
        self.dropout1 = nn.Dropout(dropout)
        self.dropout2 = nn.Dropout(dropout)

    def forward(self, x, mask=None):
        # Selbstaufmerksamkeit mit Restverbindung und Normalisierung.
        attn_out = self.self_attn(x, mask)
        x = x + self.dropout1(attn_out)
        x = self.norm1(x)
        # Feed-Forward mit Restverbindung und Normalisierung.
        ffn_out = self.ffn(x)
        x = x + self.dropout2(ffn_out)
        x = self.norm2(x)
        return x


Um den vollständigen Encoder zu erstellen, stapeln wir N solcher Schichten und wenden Positionscodierungen auf die Eingabe an:


class TransformerEncoder(nn.Module):
    def __init__(self, num_layers, d_model, num_heads, d_ff, dropout):
        super(TransformerEncoder, self).__init__()
        self.pos_encoder = get_sinusoidal_positional_encoding
        self.layers = nn.ModuleList([
            TransformerEncoderLayer(d_model, num_heads, d_ff, dropout)
            for _ in range(num_layers)
        ])
        self.norm = nn.LayerNorm(d_model)

    def forward(self, src, src_mask=None):
        # src: (batch_size, seq_len, d_model)
        seq_len = src.size(1)
        # Positionskodierung hinzufügen.
        pos_enc = self.pos_encoder(seq_len, src.size(2)).to(src.device)
        x = src + pos_enc.unsqueeze(0)
        # Durchlaufen jeder Encoder-Schicht.
        for layer in self.layers:
            x = layer(x, src_mask)
        return self.norm(x)


Die Implementierung eines Decoders folgt dem gleichen Muster, umfasst jedoch eine maskierte Selbstaufmerksamkeits-Unterschicht, um die Berücksichtigung nachfolgender Positionen zu verhindern, sowie eine Encoder-Decoder-Aufmerksamkeits-Unterschicht, die die Ausgabe des Encoders berücksichtigt. Eine abschließende lineare Softmax-Schicht ordnet die Decoder-Ausgabe den Wahrscheinlichkeiten im Zielvokabular zu.

Durch die Codierung jeder Komponente – von der Skalarprodukt-Aufmerksamkeit über Multi-Head-Aufmerksamkeit, Positionskodierung, Feed-Forward-Netzwerke bis hin zu Encoder-Schichten – erhalten Sie Einblicke in den Informationsfluss durch den Transformer. Auf dieser Grundlage lässt sich das Modell leicht an Aufgaben wie maschinelle Übersetzung, Textzusammenfassung oder sogar Bildgenerierung anpassen oder erweitern.

Um Sequenz-zu-Sequenz-Aufgaben wie maschinelle Übersetzung oder Zusammenfassung durchzuführen, müssen wir den Encoder zu einem gepaarten Decoder erweitern, der jeweils ein Token generiert und dabei die Ausgabe des Encoders berücksichtigt. Ein vollständiger Transformer umfasst somit Token-Einbettungen, Positionskodierungen, einen Stapel von Encoder-Schichten, einen Stapel von Decoder-Schichten und eine abschließende lineare Projektion in das Zielvokabular.

Nachfolgend finden Sie eine schrittweise Implementierung in PyTorch, wobei zu jeder Zeile eine Erläuterung erfolgt.


import math
import torch
import torch.nn as nn
import torch.nn.functional as F

def scaled_dot_product_attention(Q, K, V, mask=None):
    """
    Berechnet die skalierte Skalarprodukt-Aufmerksamkeit.
    
    Q, K, V sind Form (batch_size, num_heads, seq_len, d_k).
    Mask, falls angegeben, enthält -inf unzulässige Positionen.
    """
    d_k = Q.size(-1)
    
    # Berechne die rohen Aufmerksamkeitswerte durch Matrixmultiplikation der Abfragen mit den Schlüsseln.
    scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(d_k)
    # Wenn eine Maske angegeben ist, füge sie hinzu (Positionen mit -inf bleiben nach Softmax Null).
    if mask is not None:
        scores = scores + mask
    # Normalisiere die Werte zu Wahrscheinlichkeiten.
    attn_weights = F.softmax(scores, dim=-1)
    # Multipliziere die Wahrscheinlichkeiten mit den Werten, um die beachteten Ausgaben zu erhalten.
    output = torch.matmul(attn_weights, V)
    return output, attn_weights

class MultiHeadAttention(nn.Module):
    def __init__(self, d_model, num_heads):
        super(MultiHeadAttention, self).__init__()
        # Sicherstellen, dass d_model gleichmäßig durch die Anzahl der Köpfe teilbar ist.
        assert d_model % num_heads == 0
        self.num_heads = num_heads
        self.d_k = d_model // num_heads
        # Lineare Projektionen für Abfragen, Schlüssel, Werte.
        self.W_q = nn.Linear(d_model, d_model)
        self.W_k = nn.Linear(d_model, d_model)
        self.W_v = nn.Linear(d_model, d_model)
        # Endgültige lineare Projektion nach Verkettung aller Köpfe.
        self.W_o = nn.Linear(d_model, d_model)

    def forward(self, query, key, value, mask=None):
        batch_size = query.size(0)
        # Projektion der Eingabetensoren in Q, K, V.
        Q = self.W_q(query)
        K = self.W_k(key)
        V = self.W_v(value)
        # In (batch, heads, seq_len, d_k) umformen und transponieren.
        Q = Q.view(batch_size, -1, self.num_heads, self.d_k).transpose(1, 2)
        K = K.view(batch_size, -1, self.num_heads, self.d_k).transpose(1, 2)
        V = V.view(batch_size, -1, self.num_heads, self.d_k).transpose(1, 2)
        # Skalierte Skalarprodukt-Aufmerksamkeit pro Kopf anwenden.
        attn_output, _ = scaled_dot_product_attention(Q, K, V, mask)
        # Köpfe verknüpfen: zurück transponieren und Kopfdimension zusammenführen.
        concat = attn_output.transpose(1, 2).contiguous().view(batch_size, -1, self.num_heads * self.d_k)
        # Endgültige lineare Projektion.
        output = self.W_o(concat)
        return output

class PositionalEncoding(nn.Module):
    def __init__(self, d_model, max_len=5000):
        super(PositionalEncoding, self).__init__()
        # Erstelle einmal sinusförmige Positionskodierungen.
        pe = torch.zeros(max_len, d_model)
        position = torch.arange(0, max_len).unsqueeze(1).float()
        
        div_term = torch.exp(torch.arange(0, d_model, 2).float() * -(math.log(10000.0) / d_model))
        pe[:, 0::2] = torch.sin(position * div_term)
        pe[:, 1::2] = torch.cos(position * div_term)
        
        # Batch-Dimension hinzufügen und als Puffer registrieren, damit sie sich mit dem Modell mitbewegt.
        self.register_buffer('pe', pe.unsqueeze(0))

    def forward(self, x):
        # x hat die Form (batch_size, seq_len, d_model).
        # Die Positionskodierungen bis zur Eingabelänge hinzufügen.
        x = x + self.pe[:, :x.size(1)]
        return x

class TransformerEncoderLayer(nn.Module):
    def __init__(self, d_model, num_heads, d_ff, dropout):
        super(TransformerEncoderLayer, self).__init__()
        # Selbstaufmerksamkeits-Unterschicht.
        self.self_attn = MultiHeadAttention(d_model, num_heads)
        # Positionsbezogenes Feedforward-Netzwerk.
        self.ffn = nn.Sequential(
            nn.Linear(d_model, d_ff),
            nn.ReLU(),
            nn.Linear(d_ff, d_model),
        )
        # Layer-Normalisierungsmodule.
        self.norm1 = nn.LayerNorm(d_model)
        self.norm2 = nn.LayerNorm(d_model)
        # Dropout zur Regularisierung.
        self.dropout1 = nn.Dropout(dropout)
        self.dropout2 = nn.Dropout(dropout)

    def forward(self, x, src_mask=None):
        # Selbstaufmerksamkeit anwenden, dann addieren und normieren.
        attn_out = self.self_attn(x, x, x, src_mask)
        x = self.norm1(x + self.dropout1(attn_out))
        # Feedforward-Netzwerk anwenden, dann addieren und normieren.
        ffn_out = self.ffn(x)
        x = self.norm2(x + self.dropout2(ffn_out))
        return x

class TransformerDecoderLayer(nn.Module):
    def __init__(self, d_model, num_heads, d_ff, dropout):
        super(TransformerDecoderLayer, self).__init__()
        # Maskierte Selbstaufmerksamkeit für Zielsequenz.
        self.self_attn = MultiHeadAttention(d_model, num_heads)
        # Encoder-Decoder-Aufmerksamkeit für die Quelle.
        self.src_attn = MultiHeadAttention(d_model, num_heads)
        # Feed-Forward-Netzwerk.
        self.ffn = nn.Sequential(
            nn.Linear(d_model, d_ff),
            nn.ReLU(),
            nn.Linear(d_ff, d_model),
        )
        
        # Layer-Normen und Dropouts für jede Unterschicht.
        self.norm1 = nn.LayerNorm(d_model)
        self.norm2 = nn.LayerNorm(d_model)
        self.norm3 = nn.LayerNorm(d_model)
        
        self.dropout1 = nn.Dropout(dropout)
        self.dropout2 = nn.Dropout(dropout)
        self.dropout3 = nn.Dropout(dropout)

    def forward(self, x, memory, src_mask=None, tgt_mask=None):
        # Maskierte Selbstaufmerksamkeit auf dem Decodereingang.
        self_attn_out = self.self_attn(x, x, x, tgt_mask)
        x = self.norm1(x + self.dropout1(self_attn_out))
        # Encoder-Decoder-Aufmerksamkeit über Encoder-Ausgaben.
        src_attn_out = self.src_attn(x, memory, memory, src_mask)
        x = self.norm2(x + self.dropout2(src_attn_out))
        # Feed-forward und add & norm.
        ffn_out = self.ffn(x)
        x = self.norm3(x + self.dropout3(ffn_out))
        return x

class Transformer(nn.Module):
    def __init__(self,
                 src_vocab_size,
                 tgt_vocab_size,
                 d_model=512,
                 num_heads=8,
                 d_ff=2048,
                 num_encoder_layers=6,
                 num_decoder_layers=6,
                 dropout=0.1):
        super(Transformer, self).__init__()
        # Token-Einbettung für Quelle und Ziel.
        self.src_embed = nn.Sequential(
            nn.Embedding(src_vocab_size, d_model),
            PositionalEncoding(d_model)
        )
        
        self.tgt_embed = nn.Sequential(
            nn.Embedding(tgt_vocab_size, d_model),
            PositionalEncoding(d_model)
        )
        # Gestapelte Encoder- und Decoder-Schichten.
        self.encoder_layers = nn.ModuleList([
            TransformerEncoderLayer(d_model, num_heads, d_ff, dropout)
            for _ in range(num_encoder_layers)
        ])
        self.decoder_layers = nn.ModuleList([
            TransformerDecoderLayer(d_model, num_heads, d_ff, dropout)
            for _ in range(num_decoder_layers)
        ])
        # Endgültige lineare Projektion auf die Vokabulargröße.
        self.generator = nn.Linear(d_model, tgt_vocab_size)
        self.d_model = d_model

    def encode(self, src, src_mask=None):
        # Positionskodierung einbetten und hinzufügen.
        x = self.src_embed(src) * math.sqrt(self.d_model)
        # Durch jede Encoder-Schicht hindurchlaufen.
        for layer in self.encoder_layers:
            x = layer(x, src_mask)
        return x

    def decode(self, tgt, memory, src_mask=None, tgt_mask=None):
        # Ziel einbetten und Positionskodierung hinzufügen.
        x = self.tgt_embed(tgt) * math.sqrt(self.d_model)
        # Durchlaufen jeder Decoderschicht.
        for layer in self.decoder_layers:
            x = layer(x, memory, src_mask, tgt_mask)
        return x

    def forward(self, src, tgt, src_mask=None, tgt_mask=None):
        # Encoder-Ausgabe berechnen.
        memory = self.encode(src, src_mask)
        # Decoder-Ausgabe unter Berücksichtigung des Encoder-Speichers berechnen.
        output = self.decode(tgt, memory, src_mask, tgt_mask)
        # Auf Vokabular-Logits projizieren.
        return self.generator(output)

def generate_square_subsequent_mask(sz):
    """
    Erstellt eine Maske für kausale Aufmerksamkeit, sodass Position i nur
    auf Positionen ≤ i achten kann. Masken-Einträge sind 0, wo erlaubt, und
    -inf, wo nicht erlaubt.
    """
    mask = torch.triu(torch.full((sz, sz), float('-inf')), diagonal=1)
    return mask

# Anwendungsbeispiel mit Dummy-Daten:
# Vokabulargrößen und Sequenzlängen definieren.
src_vocab_size, tgt_vocab_size = 10000, 10000
batch_size, src_len, tgt_len = 2, 20, 22

# Transformer instanziieren.
model = Transformer(src_vocab_size, tgt_vocab_size)

# Beispiel für Quell- und Zieltoken-Indizes.
src = torch.randint(0, src_vocab_size, (batch_size, src_len))
tgt = torch.randint(0, tgt_vocab_size, (batch_size, tgt_len))

# Keine Füllmaske für dieses Beispiel.
src_mask = None
# Kausale Maske für den Decoder.
tgt_mask = generate_square_subsequent_mask(tgt_len)

# Der Vorwärtsdurchlauf liefert Logits der Form (batch_size, tgt_len, tgt_vocab_size).
logits = model(src, tgt, src_mask, tgt_mask)


In dieser Implementierung wendet jede Encoder-Schicht Multi-Head-Selbstaufmerksamkeit und ein positionsbezogenes Feedforward-Netzwerk an, jeweils mit Restverbindungen und Schichtnormalisierung. Jede Decoder-Schicht fügt einen maskierten Selbstaufmerksamkeitsschritt hinzu, um das Einsehen zukünftiger Token zu verhindern, sowie eine zusätzliche Encoder-Decoder-Aufmerksamkeit, die es dem Decoder ermöglicht, sich auf relevante Teile der Quellsequenz zu konzentrieren. Mit Sinuskurven erstellte Positionscodierungen fügen dem Modell Reihenfolgeinformationen hinzu, und die letzte lineare Schicht projiziert die Decoder-Ausgaben auf rohe Token-Scores.

Auf dieser Grundlage können Sie das Modell anhand von gelabelten (gepaarten) Textdaten trainieren, indem Sie einen geeigneten Verlust definieren (beispielsweise die Kreuzentropie zwischen den vorhergesagten Logits und den tatsächlichen Token-Indizes) und einen der zuvor beschriebenen Optimierer verwenden.

Diese Blogserie hat einen Rundflug über das große Terrain der Künstlichen Neuronalen Netze (KNNs) geboten. Dabei haben wir noch gar nicht alle Anwendungen betrachtet, in denen KNNs eine Rolle spielen. Hier sei exemplarisch das Beispiel Reinforcement Learning erwähnt, etwa DQN (Deep-Q Learning).

Durch ihre Struktur erweisen sich KNNs als adäquates Mittel, um statistisches Pattern-Matching durchzuführen, also um bestimmte Muster in Eingangsdaten aufzuspüren. Diese Fähigkeit kommt speziell bei Transformer-Architekturen zum Tragen, die Prompts verarbeiten, um daraus Rückmeldungen zu liefern. Zusätzlich findet dort häufig Reinforcement Learning statt, um die Large Language Models zu bestimmten gewünschten Abläufen zu „überreden“, etwa zum sogenannten Reasoning.

Heutige KNNs sind an biologische neuronale Netze (BNNs) angelehnt, sind diesen gegenüber aber gewaltig eingeschränkt. In Zukunft könnten Wissenschaftler versuchen, sich bei KNNs noch deutlicher ihren biologischen Vorbildern anzunähern. Insgesamt dürften Künstliche Neuronale Netze in der Zukunft Generative KI eine fundamentale und zentrale Rolle spielen.


(rme)



Source link

Entwicklung & Code

Kommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Ein neues, kostenloses Git-Management-Tool vereinfacht die Arbeit mit der Versionierungssoftware Git. Viele Funktionen lassen sich zusammenfassen oder schnell und übersichtlich ausführen, auch in älteren Commits. Dabei verwaltet es mehrere lokale Repositories gleichzeitig.

Weiterlesen nach der Anzeige

Anbieter RemObjects schreibt im Blog, dass das macOS-Tool GitBrowser die Alltagsaufgaben von Entwicklerinnen und Entwicklern beim Versionsmanagement beschleunigen soll. Das Fenster des Tools ist dreigeteilt: In der linken Sidebar findet sich eine Liste der Repos, die sich gruppieren und umbenennen lassen. Entwickler führen hier Aktionen über das Kontextmenü aus – auch in nicht aktiven Projekten.

Der Mittelteil zeigt die Versionen eines Repos, und zwar noch zu pushende in Fett, noch zu pullende kursiv und noch zu mergende blau. Auch die verschiedenen Autoren sind farblich unterschiedlich gekennzeichnet. Rechts im Fenster finden sich die betroffenen Dateien eines Commits und darunter eine Diff-Ansicht. Bei Doppelklick auf einen Commit öffnet sich ein Diff-Tool des Anwenders, derzeit Araxis Merge oder BBEdit. Weitere sollen laut Anbieter hinzukommen.

Ganz oben im Fenster steht der lokale Status, beim Klick darauf öffnet sich rechts die Bühne mit Checkboxen zum Hinzufügen oder Entfernen von Dateien. Darunter steht ein dreifach Diff: eine originale, lokale und auf der Stage liegende Variante.

Commiten und Pushen lässt sich mit einem Klick, und die Commit-Nachricht lässt sich auf Wunsch bereits beim Stagen von einer KI erzeugen. Möglich sind hier OpenAI, Claude, Gemini, Grok, Mistral oder eine lokale Verknüpfung mit LM Studio. Wer selbst die Nachricht schreibt, kann mit Pfeiltasten in älteren Ausgaben blättern.

Pullen lassen sich alle Repos auf einen Schlag oder alle einer Gruppe. Anwender ziehen Dateien, auch aus älteren Commits, per Drag-and-drop in andere Tools – ohne Checkout – GitBrowser extrahiert sie automatisch. Der Wechsel zwischen Zweigen erfolgt einfach über einen Popup-Button.

Der Anbieter betont im Blog, dass GitBrowser nicht für tiefergehende Funktionen gedacht sei, sondern alltägliche Verwaltungsvorgänge erleichtern soll. Anspruchsvolle Anwenderinnen und Anwender werden ganz ohne Kommandozeile also doch nicht auskommen.

Weiterlesen nach der Anzeige

Lesen Sie auch


(who)



Source link

Weiterlesen

Entwicklung & Code

Clean Architecture und Co.: Softwarearchitektur mit Mustern strukturieren


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

Strukturierte Software basiert auf einem Plan, der die spezifischen Anforderungen an ein System berücksichtigt und in lose gekoppelte Bausteine überführt. In der arbeitsteiligen Softwareentwicklung benötigen Entwicklungsteams solche gemeinsamen Pläne, um eine harmonische und einheitliche Architektur zu entwickeln, ohne jedes Detail vorab miteinander abstimmen zu müssen. Bewähren sich die Pläne, entwickeln sich daraus Muster und Prinzipien auf unterschiedlichen Architekturebenen.

Weiterlesen nach der Anzeige


Matthias Eschhole

Matthias Eschhole

Matthias Eschhold ist Lead-Architekt der E-Mobilität bei der EnBW AG. Als Experte für Domain-driven Design gestaltet er die IT-Landschaft und Team-Topologien der E-Mobilität. Trotz strategischer Schwerpunkte bleibt er mit Java und Spring Boot nah am Code, entwickelt Prototypen und führt Refactorings durch. Als Trainer vermittelt er seit Jahren praxisnahe Softwarearchitektur, die Theorie und Projektrealität verbindet.

Bei der grundlegenden Strukturierung eines Systems muss man zwischen Architekturstilen und Architekturmustern unterscheiden, wobei sie sich nicht immer sauber abgrenzen. Ein Architekturstil ist ein Mittel, das dem System eine grundlegende Struktur verleiht. Beim Stil Event-driven Architecture basiert die Anwendung beispielsweise auf asynchroner Kommunikation, und Events beeinflussen die Architektur und den Code an vielen Stellen. Gleiches gilt für REST, das eine ressourcenorientierte Struktur vorgibt.

Entscheidet sich ein Entwicklungsteam für Microservices als Architekturstil, wählt es eine verteilte Systemarchitektur, beim Stil Modularer Monolith ist das Gegenteil der Fall. In komplexen Systemen kombinieren Architektinnen und Architekten in der Regel mehrere Stile. Manche Architekturstile ergänzen sich, etwa REST und Microservices, während sich andere gegenseitig ausschließen, wie Microservices und der Modulare Monolith.

Ob Microservices oder Modularer Monolith – beides sagt wenig über die Gestaltung der internen Strukturen aus. Auf dieser inneren Architekturebene, der Anwendungsarchitektur, kommen Muster zum Einsatz, die Entwurfsprinzipien und -regeln kombinieren und eine Basisstruktur der Anwendung prägen. Architekturmuster der Anwendungsarchitektur nutzen Verantwortungsbereiche und Beziehungsregeln als Strukturierungsmittel. Im Muster Clean Architecture sind dies beispielsweise konzentrische Ringe, wobei die Beziehungsrichtung stets zum inneren Kern des Ringmodells führt. Die geschichtete Architektur (Layered Architecture) hingegen unterteilt die Verantwortungsbereiche in hierarchische Schichten, wobei jede Schicht nur mit der darunter liegenden kommunizieren darf (siehe Abbildung 1).


Infografik Vergleich zwischen Clean Architecture und Schichtenarchitektur

Infografik Vergleich zwischen Clean Architecture und Schichtenarchitektur

Vergleich zwischen Clean Architecture und Schichtenarchitektur (Abb. 1).

Eine Mustersprache ergänzt Architekturmuster für einen ganzheitlichen Konstruktionsplan – von Modulen und Paketen bis hin zum Klassendesign. Sie bildet das Fundament für eine konsistente und verständliche Umsetzung der Muster und beschreibt eine Reihe von Entwurfsmustern für die Programmierung auf der Klassenebene.

Weiterlesen nach der Anzeige

Die Klassen der Mustersprache bilden Geschäftsobjekte, Fachlogik und technische Komponenten ab. Sie werden unter Einhaltung der definierten Beziehungsregeln in einem Klassenverbund implementiert. Diese Regeln bestimmen, wie die Klassen miteinander interagieren, wie sie voneinander abhängen und welche Aufgaben sie haben. Ein Geschäftsobjekt ist charakterisiert durch seine Eigenschaften und sein Verhalten, während ein Service Geschäftslogik und fachliche Ablaufsteuerung implementiert. Eine derartige, genaue Differenzierung gestaltet Architektur klar und nachvollziehbar.

Ein wichtiger Aspekt einer Mustersprache ist die Organisation des Codes in einer gut verständlichen Hierarchie. Dadurch fördert sie die Verteilung von Verantwortlichkeiten auf unterschiedliche Klassen. Prinzipiell kann jedes Projekt seine eigene Mustersprache definieren oder eine bestehende als Basis verwenden und mit individuellen Anforderungen ausbauen. Eine Mustersprache sorgt auch im Team dafür, dass alle Mitglieder dieselben Begriffe und Prinzipien verwenden.

Dieser Artikel wählt die DDD Building Blocks als Grundlage für eine Mustersprache, wie die folgende Tabelle und Abbildung 2 zeigen.

Value Object Ein Value Object repräsentiert einen unveränderlichen Fachwert ohne eigene Entität. Das Value Object ist verantwortlich für die Validierung des fachlichen Werts und sollte nur in einem validen Zustand erzeugt werden können. Ferner implementiert ein Value Object dazugehörige Fachlogik.
Entity Eine Entity ist ein Objekt mit einer eindeutigen Identität und einem Lebenszyklus. Die Entität wird beschrieben durch Value Objects und ist verantwortlich für die Validierung fachwertübergreifender Geschäftsregeln sowie die Implementierung dazugehöriger Fachlogik.
Aggregate Ein Aggregate ist eine Sammlung von Entitäten und Value Objects, die durch eine Root Entity (oder Aggregate Root bzw. vereinfacht Aggregate) zusammengehalten werden. Die Root Entity definiert eine fachliche Konsistenzgrenze, klar abgegrenzt zu anderen Root Entities (oder Aggregates).
Domain Service Ein Domain Service implementiert Geschäftslogik, die nicht zu einer Entität oder einem Value Object gehört. Weiter steuert der Domain Service den Ablauf eines Anwendungsfalls. Ein Domain Service ist zustandslos zu implementieren.
Factory Eine Factory ist für die Erstellung von Aggregates, Entitäten oder Value Objects verantwortlich. Die Factory kapselt die Erstellungslogik komplexer Domänenobjekte.
Repository Ein Repository ist verantwortlich für die Speicherung und das Abrufen von Aggregaten und Entitäten aus einer Datenquelle. Das Repository kapselt den Zugriff auf eine Datenbank oder auch andere technische Komponenten.


Infografik Mustersprache des taktischen Domain-driven Design

Infografik Mustersprache des taktischen Domain-driven Design

Mustersprache des taktischen Domain-driven Design (Abb. 2).

Ein Beispiel verdeutlicht den Unterschied zwischen einem Value Object und einer Entity: Eine Entity könnte ein bestimmtes Elektrofahrzeug sein. Entities sind also eindeutig und unverwechselbar. In der realen Welt zeigt sich das an der global eindeutigen Fahrgestellnummer (VIN). Der aktuelle Zustand eines E-Fahrzeugs wird zu einem bestimmten Zeitpunkt beispielsweise durch seinen Ladezustand beschrieben, ein Wert, der sich im Laufe der Nutzung des Fahrzeugs verändert. Der Ladezustand entspricht einem Value Object. Er verfügt über keine eigene Identität, sondern definiert sich ausschließlich durch seinen Wert.

Die Mustersprache der Building Blocks ist nicht vollständig. Sie benötigt weitere Elemente, die von den eingesetzten Architekturstilen und -mustern abhängen. REST als Architekturstil führt beispielsweise zwei Elemente in die Mustersprache ein: Controller und Resource. Bei der Integration von REST als Provider liegt der Fokus auf der Resource, die als Datentransferobjekt (DTO) über den API-Endpunkt bereitsteht. Der Controller fungiert als Schnittstelle zwischen der Anfrage des Konsumenten und der Fachlogik des Systems. Das heißt, der Controller nutzt den bereits eingeführten Domain Service und delegiert die Ausführung von Fachlogik an diesen.

Bei der Integration von REST als Consumer erhält die Mustersprache das Element Service Client, das dem Abrufen von Daten oder Ausführen von Funktionen über einen externen API-Endpunkt dient. Der Domain Service triggert dies als Teil der Fachlogik über den Service Client.

Der Stil Event-driven Architecture erweitert die Mustersprache um die Elemente Event Listener, Event Publisher und das Event selbst. Ein Event Listener hört auf Ereignisse und ruft den entsprechenden Domain Service auf, um die Ausführung der Geschäftslogik auszulösen. Der Event Publisher veröffentlicht eine Zustandsveränderung in der Fachlichkeit über ein Event. Der Domain Service triggert die Event-Veröffentlichung als Teil seiner Fachlogik und nutzt hierfür den Event Publisher.

Die in diesen Beispielen aufgeführten Begriffe sind im Vergleich zu den DDD Building Blocks nicht in der Literatur definiert und entstammen der Praxis. Abbildung 3 zeigt die Klassen der erweiterten Mustersprache.


Infografik Elemente der Mustersprache des taktischen Domain-driven Design

Infografik Elemente der Mustersprache des taktischen Domain-driven Design

Elemente der Mustersprache des taktischen Domain-driven Design (Abb. 3).

Architekturmuster kombinieren Regeln, Entwurfsmuster und Prinzipien. Muster wie Clean Architecture, die sich besonders für komplexe Systeme mit hohen Anforderungen an den Lebenszyklus eignen, bündeln mehrere Konzepte und beeinflussen daher die Mustersprache stärker als andere Muster. Ein Beispiel ist das Konzept Use Case in der Clean Architecture, das ein zentrales Element darstellt und die Mustersprache um die Elemente Use Case Input Port, Use Case Output Port und Use Case Interactor erweitert. Ein weiteres Beispiel ist die Anwendung des Dependency Inversion Principle (DIP) in der Clean Architecture, das zu dem Musterelement Mapper führt.

Nach dem Exkurs über die Mustersprachen stellt dieser Artikel verschiedene Architekturmuster vor, die sich in schichten- und domänenbasierende unterteilen.

Schichtenbasierende Architekturmuster sind datenzentrisch strukturiert. Je nach Muster ist dieser Aspekt mehr oder weniger ausgeprägt. Die Schichtung unterscheidet sich in technischer (horizontal geschnitten) und fachlicher (vertikal geschnitten) Hinsicht. Für die weitere Beschreibung eignet sich die Begriffswelt von Simon Brown mit „Package by …“ .

Package by Layer: Dieses Muster organisiert die Anwendung nach technischen Aspekten, zum Beispiel nach Controller, Service und Repository (Abbildung 4). Es kommt jedoch schnell an seine Grenzen: Mittlere und große Systeme mit komplizierter Fachlichkeit erfordern eine vertikale Schichtung anhand fachlicher Aspekte, andernfalls enden die Projekte erfahrungsgemäß in komplizierten Monolithen mit vielen Architekturverletzungen.

Vorteile:

  • Bekannt und verbreitet
  • Einfach zu verstehen und anzuwenden
  • In kleinen Projekten praktikabel

Nachteile:

  • Enge Kopplung zwischen Schichten, mit der Gefahr chaotischer Abhängigkeiten bei Wachstum des Systems
  • Fachlich zusammenhängende Funktionalitäten sind über viele Pakete verteilt
  • Schwer wartbar und erweiterbar bei mittleren bis großen Anwendungen


Infografik Das Architekturmuster Package by Layer

Infografik Das Architekturmuster Package by Layer

Das Architekturmuster Package by Layer (Abb. 4).

Package by Feature: Der Code organisiert sich vertikal anhand fachlicher Aspekte. Eine Schnitt-Heuristik, wie genau das Feature von den fachlichen Anforderungen abzuleiten ist, definiert das Architekturmuster nicht. Es definiert nur, dass dieser fachliche Schnitt zu erfolgen hat. Wird das taktische DDD angewendet, erfolgt der Schnitt entlang der Aggregates (siehe Abbildung 5).

Vorteile:

  • Fachlich kohäsiver Code ist lokal zusammengefasst, was zu hoher Wartbarkeit und Erweiterbarkeit führt.
  • Modularisierung ermöglicht die unabhängige Entwicklung fachlicher Module.
  • Fachliche Ende-zu-Ende-Komponenten sind lose gekoppelt.
  • Abhängigkeiten zwischen fachlichen Modulen müssen explizit gehandhabt werden, was die Robustheit der Architektur gegenüber ungewünschten Abhängigkeiten erhöht.
  • Fachlich komplexe, mittelgroße bis große Anwendungen lassen sich mit vertikalen Schichten besser beherrschen als mit Package by Layer und Package by Component.

Nachteile:

  • Abhängigkeiten zwischen fachlichen Modulen erfordern fortgeschrittene Kommunikationsmuster (zum Beispiel Events), was die architektonische Komplexität erhöht.
  • Vertikale Modularisierung muss gut durchdacht werden, um enge Kopplung zwischen Modulen zu vermeiden.


Infografik Architekturmuster Package by Feature

Infografik Architekturmuster Package by Feature

Das Architekturmuster Package by Feature (Abb. 5).

Package by Component: Das Muster strukturiert die Anwendung sowohl fachlich (vertikal) als auch technisch (horizontal), wobei sich ein fachliches Feature in eine Inbound-Komponente und eine Domain-Komponente aufteilt (siehe Abbildung 6). Die Domain-Komponente kapselt Geschäftslogik und die dazugehörige Persistenzschicht. Diese Unterteilung in fachliche Module ist ein entscheidender Unterschied zu Package by Layer.

Vorteile:

  • Gute Modularisierung durch fachliche Grenzen zwischen Komponenten
  • Hohe Wiederverwendbarkeit der Domain-Komponenten, durch unterschiedliche Inbound-Komponenten
  • Erleichterte Testbarkeit durch gesteigerte Modularisierung im Vergleich zu Package by Layer

Nachteile:

  • Enge Kopplung zwischen Inbound- und Domain-Schicht, mit dem Risiko indirekter Abhängigkeiten und Seiteneffekten bei Änderungen, insbesondere wenn die Anwendung wächst
  • Komponentenkommunikation schwer beherrschbar bei erhöhter fachlicher Komplexität
  • Schwerer erweiterbar für mittlere bis große Anwendungen mit höherer fachlicher Komplexität


Infografik Architekturmuster in Package by Component (Abb. 6).

Infografik Architekturmuster in Package by Component (Abb. 6).

Das Architekturmuster in Package by Component (Abb. 6).



Source link

Weiterlesen

Entwicklung & Code

Ein Tag im Leben eines Softwarearchitekten – Überleben im Unternehmensdschungel


Heute erzähle ich von einem typischen Arbeitstag als Softwarearchitekt, der schon vor dem Weg zur Arbeit beginnt.

Weiterlesen nach der Anzeige


Michael Stal

Michael Stal

Prof. Dr. Michael Stal arbeitet seit 1991 bei Siemens Technology. Seine Forschungsschwerpunkte umfassen Softwarearchitekturen für große komplexe Systeme (Verteilte Systeme, Cloud Computing, IIoT), Eingebettte Systeme und Künstliche Intelligenz.

Er berät Geschäftsbereiche in Softwarearchitekturfragen und ist für die Architekturausbildung der Senior-Software-Architekten bei Siemens verantwortlich.

Der Wecker schreit mit der Begeisterung eines Junior-Entwicklers, der gerade Designmuster entdeckt hat. Als Softwarearchitekt beginnt mein Tag nicht mit Kaffee, sondern mit einem kurzen Blick auf die Produktionswarnungen der letzten Nacht. Drei kritische Systeme sind ausgefallen, zwei Datenbanken laufen aus unerfindlichen Gründen so, als würden sie auf einem Server aus dem Jahr 1995 mit einem antiken Prozessor laufen, und es gibt eine dringende Slack-Nachricht von jemandem, der fragt, ob wir „einfach schnell Blockchain zu unserem Warenkorb hinzufügen können, weil der CEO gehört hat, dass das revolutionär ist“.

Ich schenke mir eine Tasse Kaffee ein, der so stark ist, dass er wahrscheinlich selbst Code kompilieren könnte, und bereite mich mental auf einen weiteren Tag vor, an dem ich Geschäftsträume in technische Realität umsetzen und mich dabei durch die tückischen Gewässer der Unternehmensbürokratie navigieren muss.

Während meiner Fahrt zur Arbeit erhalte ich den ersten von insgesamt siebzehn Anrufen, die ich heute erhalten werde. Er kommt vom Projektmanager, der entdeckt hat, dass unsere sorgfältig geplante Microservices-Architektur möglicherweise mehrere Dienste erfordert. Der Horror! Ich verbringe zwanzig Minuten damit, zu erklären, warum „einfach einen großen Dienst daraus zu machen“ den Zweck der letzten Sechs-Monats-Planung zunichtemacht. Dieses Gespräch wird sich heute noch viermal mit verschiedenen Personen wiederholen, die offenbar an derselben Besprechung teilgenommen haben, aber völlig unterschiedliche Dinge gehört haben wollen.



Source link

Weiterlesen

Beliebt