Kommunikationsmuster

Kapitel 1. Grundlagen der Kommunikation

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Dieses Kapitel liefert die Grundlage, auf der du mit den anderen Mustern in Teil I aufbauen wirst. Wenn ich von Mustern und Gegenmustern spreche, meine ich Folgendes:

Muster

Eine wiederverwendbare Lösung, von der bekannt ist, dass sie wirksam ist, wenn sie zur Lösung eines bestimmten oder allgemeineren Problems eingesetzt wird, die auch als Techniken, Praktiken, Methoden oder Regeln bezeichnet werden können.

Antipattern

Eine Lösung, die nicht zu empfehlen ist. Sie sieht so aus, als wäre sie der richtige Weg, um ein Problem zu lösen, aber in Wirklichkeit überwiegen die Folgen die Vorteile.

Ich empfehle dir dringend, die Muster und Gegenmuster in diesem Kapitel anzuwenden, bevor du mit allen anderen darauf aufbaust. Stell dir das so vor, als würdest du ein Gebäude bauen: Erst muss das Fundament stimmen, bevor du die Wände, Böden und das Dach bauen kannst. Fang nicht an, auf Sand zu bauen, sonst wird dein Bauwerk untergehen. Sorge zuerst für das richtige Fundament.

Kenne dein Publikum

Das Muster "Kenne dein Publikum" ist auch bekannt als " Verstehe deinen Kunden". Einer der wichtigsten Faktoren, die du bei der Erstellung und Bearbeitung eines Diagramms berücksichtigen musst, ist die Frage, wer es sehen und lesen wird. Der Zweck deines Diagramms ist es, erfolgreich mit dieser Zielgruppe zu kommunizieren. Um dies zu erreichen, ist es wichtig zu wissen, wer dein Kunde ist, und das Diagramm auf seine Bedürfnisse abzustimmen.

Die Personen , die dein Diagramm ansehen, könnten folgende Rollen haben:

• Entwickler (Full-Stack, Frontend, Backend...)

• Architekten (technisch, Lösung,Sicherheit...)

• Business-Analysten

• Produktbesitzer

• Projektleiter

• Kunden

• Teams unterstützen

Tipp

Erstelle eine Liste der Rollen, die deine Diagramme ansehen, und gruppiere die Rollen dann nach den Arten von Diagrammen, die du erstellst. Du wirst wahrscheinlich feststellen, dass du für verschiedene Diagramme unterschiedliche Zielgruppen hast. Nutze diese Listen für die Fragen am Ende dieses Abschnitts.

Die folgenden Diagramme wurden für verschiedene Zielgruppen erstellt und die Art des Diagramms und die Schreibweise wurden entsprechend der Zielgruppe gewählt.

Abbildung 1-1 zeigt ein Unified Modeling Language (UML) Klassendiagramm, das sich an ein technisches Publikum richtet, darunter Entwickler, Architekten und Datenbankadministratoren. Es ist unwahrscheinlich, dass ein Product Owner oder Projektmanager die Informationen in diesem Diagramm braucht oder es ohne Hilfe verstehen kann.

Abbildung 1-1. UML-Klassendiagramm, das sich an ein technisches Publikum richtet

Abbildung 1-2 ist ein C4 Kontextdiagramm. Es ist ein vielseitiges Diagramm, das sowohl für technische als auch für geschäftliche Zielgruppen nützlich ist, um sich einen Überblick über ein System zu verschaffen. Dieses Diagramm ist für Rollen wie Product Owner, Projektmanager, Architekt, Entwickler und Business Analysten gleichermaßen lesbar und nützlich.

Abbildung 1-2. C4-Kontextdiagramm, nützlich für die meisten Zielgruppen

Die in Abbildung 1-3 gezeigte Domain Story richtet sich eher an die Geschäftsrollen, aber auch an die technischen Rollen, die an der Umsetzung der Geschäftsanforderungen in technische Lösungen beteiligt sind. Domänengeschichten werden erstellt, um die Kommunikation zwischen den Geschäftsinteressenten und den technischen Rollen zu verbessern, damit die Lösung den Anforderungen des Unternehmens und der Nutzer entspricht. An der Erstellung und Überprüfung einer Domain Story sind Fachexperten (SMEs) aus dem Bereich oder beteiligt, ebenso wie Product Owner (wenn sie nicht selbst SME sind), Business Analysten und Architekten.

Abbildung 1-3. Domain-Story-Diagramm, das sich an Geschäftsrollen und technische Übersetzerrollen wie Architekten und Business-Analysten richtet

Nachdem du deine Zielgruppe ermittelt hast, frage dich Folgendes über sie:

Was wollen sie von dir?

Berücksichtige die Erwartungen und Bedürfnisse deines Publikums. Ihre Bedürfnisse zu erfüllen ist der Schlüssel zu einer erfolgreichen Kommunikation. Sucht dein Publikum nach bestimmten Informationen, damit es eine Entscheidung treffen oder jemandem Bericht erstatten kann? Sorge dafür, dass deine Zielgruppe zufrieden ist, indem du sie mit den Informationen und dem Verständnis versorgst, die sie für ihre Arbeit braucht.

Was willst du von ihnen?

Diese Frage wird oft übersehen: was du von deinem Publikum brauchst. Brauchst du Zustimmung oder Zustimmung zu deinen Designentscheidungen? Musst du sie dazu bringen, eine Entscheidung auf der Grundlage deiner Diagramme zu treffen? Vergewissere dich, dass deine Zuhörer/innen wissen, was du von ihnen erwartest, und dass sie alles haben, was sie brauchen, um deine Erwartungen zu erfüllen.

Wie ist ihr technisches Verständnis?

Das technische Verständnis deines Publikums bestimmt die Art des Diagramms, von dem es profitieren wird. Überlege, wie technisch dein Projektmanager ist. Möchte dein Produktverantwortlicher etwas über die ausgewählte Technologie erfahren oder nur darüber, wie gut sie die Anforderungen erfüllt?

Wie detailliert müssen sie sein?

Unabhängig davon, ob der Inhalt technisch ist oder nicht, musst du den richtigen Detaillierungsgrad berücksichtigen. Ist das Diagramm für ein Architekturprüfungsgremium bestimmt, das viele Details erwarten wird? Benötigt das Entwicklungsteam Details zur Umsetzung, oder gehört es zu seinen Aufgaben, diese Details festzulegen?¹ Frag die Teams, was sie wollen, und halte dich nicht an die schriftlichen oder ungeschriebenen Richtlinien, die dir das Unternehmen gibt. Wenn es Regeln gibt, die den Bedürfnissen des Teams nicht entsprechen, sprich mit der zuständigen Person darüber.

Neben diesen Fragen solltest du auch bedenken, dass deine Zuhörer/innen die Sprache, die du verwendest, vielleicht nicht als Muttersprache sprechen und einen anderen kulturellen Hintergrund haben als du (siehe "Einfache Sprache").

Sobald du deine Zielgruppe und ihre Bedürfnisse erkannt hast, kannst du mit deinem Diagramm beginnen.

Mischen von Abstraktionsebenen

Die Vermischung von Abstraktionsebenen ist ein Kommunikationsmuster, das ein Gegenstück in der Welt der Programmierung hat. Wenn du schon einmal programmiert hast, kennst du die Vermischung von Abstraktionsebenen wahrscheinlich als Sünde oder als Codegeruch.² Auch wenn es sinnvoll erscheint, alle Informationen, die jemand brauchen könnte, in ein Diagramm zu packen, führt das aus Sicht der Zuhörer/innen zu Unordnung und Verwirrung.

Hinweis

Die Abstraktionsebene bezieht sich auf die Granularität oder Allgemeinheit der Informationen, die du in einem Diagramm darstellst. Die Abstraktionsebenen reichen von High-Level-Ansichten, die die wichtigsten Komponenten eines Systems und ihre Beziehungen zueinander zeigen, bis hin zu Low-Level-Diagrammen, die die Struktur des Codes detailliert darstellen.

Wenn du verschiedene Abstraktionsebenen in mehreren Diagrammen verwendest, kannst du für die Zielgruppe angemessen kommunizieren und gleichzeitig sicherstellen, dass alle relevanten Informationen erfasst werden.

Jede Software ist eine Abstraktion, aber im Wesentlichen lassen sich mit Abstraktionsebenen Details auf niedriger Ebene vor Konzepten auf hoher Ebene verbergen. Entwickler/innen schreiben Software nicht mit Einsen und Nullen (Binär- oder Maschinencode), sondern in höheren Sprachen, die die Komplexität des Maschinencodes und aller dazwischen liegenden Ebenen (Interpreter, Compiler usw.) abstrahieren.

Wirf einen Blick auf Abbildung 1-4. Wenn du dir den Weg zur Arbeit als eine Abstraktionsebene vorstellst, könnte die nächste Ebene die Konzepte Aufstehen, Duschen, Anziehen, Frühstücken, Verlassen des Hauses und so weiter enthalten. Die nächste Ebene für das Aufstehen würde das Zurückschieben der Decke, das Aufsetzen und Aufstehen beinhalten. Du hast also drei Abstraktionsebenen (zur Arbeit gehen, aufstehen, dieDecke zurückschieben), aber in der Software sollten sie alle getrennt sein (z. B. in verschiedenen Methoden oder Klassen), um Verwirrung und unnötige Komplexität zu vermeiden und die Lesbarkeit zu verbessern.

Abbildung 1-4. Abstraktionsebenen im täglichen Leben

Die Verwendung von Abstraktionsebenen gilt für Softwarearchitektur und Diagramme in gleicher Weise. Im Code wendest du dieses Prinzip auf Methoden, Klassen, Schichten in einer mehrschichtigen Anwendung (z. B. eine Präsentationsschicht, die Geschäftslogik, eine Persistenzschicht und den Datenspeicher) und mehr an. In Diagrammen und in der Softwarearchitektur wendest du dieses Prinzip auf den Inhalt von Diagrammen und auf die Struktur von Diensten, Microservices, und so weiter an.

Das C4-Modell ist eine Hierarchie von Abstraktionen. Es verfolgt einen Ansatz, bei dem die Abstraktion an erster Stelle steht und alles andere darum herum aufgebaut wird. Seine vier Abstraktionsschichten definieren die Kerndiagramme:³

1. Der Systemkontext zeigt einen Überblick über das System und wie es sich in seine Umgebung einfügt, einschließlich der Interaktionen zwischen dem System und anderen Einheiten.

2. Die Containerebene zoomt auf das betrachtete Softwaresystem und zeigt die High-Level-Komponenten oder Bausteine und wie sie miteinander und mit externen Einheiten interagieren.

3. Die Komponentenebene zoomt weiter auf einen einzelnen Container aus der vorherigen Ebene heran. Sie zeigt die Komponenten innerhalb des Containers und ihre Interaktionen untereinander und mit externen Einheiten.

4. Die Code-Ebene zoomt noch weiter auf eine Komponente aus der vorherigen Ebene heran. Sie zeigt, wie die Komponente implementiert ist. (Diese Ebene ist oft detaillierter, als es für deine Dokumentation notwendig ist).

Du kannst dir diese vier Ebenen als Karten vorstellen, die du vergrößern kannst, um immer mehr Details zu entdecken. Die C4-Abstraktionsebenen können den Bedarf an unterschiedlichen Detailstufen verdeutlichen.

Abbildung 1-5 ist weder ein Kontextdiagramm noch ein Containerdiagramm. Es ist eine Mischung aus zwei Abstraktionsebenen. Wenn du dir das Diagramm genau ansiehst, ergibt es keinen Sinn. Das System, um das es geht (das Softwaresystem von Polyglot Media), scheint teilweise in Container aufgeteilt worden zu sein, und die Beziehung zwischen dem Softwaresystem und den Containern ergibt keinen Sinn. Das Softwaresystem und die Container gehören auf unterschiedliche konzeptionelle Ebenen. In Wirklichkeit interagieren die Container innerhalb des Softwaresystems mit den dargestellten Containern.

Abbildung 1-5. C4-Diagramm, das sowohl die Kontext- als auch die Containerebene der Abstraktion zeigt(Antipattern)

Abbildung 1-6 zeigt, wie das Kontextdiagramm für Abbildung 1-5 aussehen sollte. Hier befindet sich das Softwaresystem, das im Fokus steht (Polyglot Media), mit den dazugehörigen externen Systemen und Akteuren.

Abbildung 1-6. C4-Kontextdiagramm

Abbildung 1-7 zeigt, wie die Informationen der Container-Abstraktionsschicht in Abbildung 1-5 in einem C4-Containerdiagramm dargestellt werden sollten. Das System im Fokus (Polyglot Media) wird als gestrichelter Kasten mit den Containern darin dargestellt.

C4-Modelle, die auf einer Hierarchie von Abstraktionen basieren, eignen sich hervorragend, um die Notwendigkeit zu verdeutlichen, Abstraktionsebenen in Diagrammen getrennt zu halten. Diese Trennungsregel gilt für alle Arten von Diagrammen. Wende sie auf deine Sequenzdiagramme, Datenflussdiagramme, Diagramme ohne formale Notation und alle anderen Diagrammtypen an, die du verwendest. Alle deine Diagramme sollten dieser Regel folgen; sie ist für die Kommunikation unerlässlich.

Wenn du deine gemischten Diagramme so aufgeteilt hast, dass sie jeweils nur eine Abstraktionsebene haben, erfährst du im Folgenden, wie du sie leicht navigierbar machst .

Abbildung 1-7. C4-Container-Diagramm

Konsistenz der Darstellung

Die Verwendung des Musters der Darstellungskonsistenz ist der nächste Schritt nach der Überprüfung der Abstraktionsebenen: Die einzelnen Diagramme werden so miteinander verbunden, dass dein Publikum leicht zwischen ihnen navigieren und sehen kann, wie sie zusammenpassen. Für dein Publikum sollte es einfach sein zu verstehen, wie deine Diagramme miteinander zusammenhängen. Du riskierst eine erfolglose Kommunikation, wenn dein Publikum zu viel nachdenken oder sich an ein wichtiges oder entscheidendes Detail erinnern muss, um die Beziehungen zwischen den Diagrammen (die jeweils eine eigene Abstraktionsebene darstellen) zu verstehen.

Viele Notationen, wie C4- und Datenflussdiagramme, verfügen über formale und explizite Möglichkeiten, die Konsistenz der Darstellung zu vermitteln. Wie bereits erwähnt, haben C4-Diagramme auch explizite Abstraktionsebenen (Kontext, Container, Komponente und Code). In Abbildung 1-8 siehst du das System im Anwendungsbereich (Polyglot Media) in der Mitte des Diagramms. Diese Kontextebene ist die höchste in C4-Diagrammen.

Abbildung 1-8. C4-Kontextdiagramm

Die nächste Ebene darunter ist ein C4-Container-Diagramm(Abbildung 1-9). Die Methode zur Verbindung dieser Diagramme ist ein gestricheltes Kästchen in Abbildung 1-9, das (unten links) genauso beschriftet ist wie das zentrale Kästchen (Polyglot Media) in Abbildung 1-8. So kann das Publikum die Verbindung zwischen diesen beiden Diagrammen sehen, egal welches es zuerst sieht.

Abbildung 1-9. C4-Container-Diagramm für Polyglot Media (zeigt die High-Level-Interaktionen innerhalb des Polyglot Media-Systems)

In einem Datenflussdiagramm verwendest du Zahlen und Buchstaben, um die Identität der Elemente zu kennzeichnen, und dann kannst du dieselben Zahlen und Buchstaben verwenden, um dein Publikum durch die verschiedenen Ebenen zu führen (die in verschiedenen Diagrammen dargestellt werden). In Abbildung 1-10 sind die Prozesse zum Beispiel von 1 bis 3 nummeriert, um die Reihenfolge anzugeben, in der sie ablaufen. Wenn diese Prozesse in einem anderen Diagramm weiter unterteilt werden, können sie anhand dieser Nummer identifiziert werden.

Abbildung 1-10. Datenflussdiagramm der Ebene 1

In Abbildung 1-11 ist der Prozess 2 aus Abbildung 1-10 in drei Unterprozesse unterteilt. Du erkennst das daran, dass sie mit 2.1 bis 2.3 nummeriert sind. Die Prozesse sind wieder geordnet, aber relativ zu dem übergeordneten Diagramm in Abbildung 1-10.

Abbildung 1-11. Datenflussdiagramm der Ebene 2

Wenn du die Datenspeicher in den Abbildungen 1-10 und 1-11 vergleichst, wirst du feststellen, dass die Datenspeicher mit den Bezeichnungen A und B in Abbildung 1-10 auch in Abbildung 1-11 mit denselbenBezeichnungen erscheinen.⁴

Wenn die Notation, die du verwendest, keine formale Möglichkeit bietet, Diagramme zu verbinden, musst du die Verbindung selbst explizit machen. Abbildung 1-12 zeigt zum Beispiel eine weitere Möglichkeit, den Prozess 2 (Medien abholen) in Abbildung 1-10 und seine Unterprozesse 2.1 bis 2.3 in Abbildung 1-11 zu verbinden, und zwar mit einer ähnlichen Methode wie bei den C4-Diagrammen (siehe Abbildung 1-9). Du kannst eine ähnliche Technik in vielen Diagrammtypen verwenden.

Abbildung 1-12. Datenflussdiagramm der Ebene 2 mit expliziter Darstellungskonsistenz

Tipp

Wenn du Diagramme in die Dokumentation aufnimmst, verweise auf sie im Text der Dokumentation. Verwende möglichst Hyperlinks und beschrifte deine Diagramme (z. B. "Abbildung 1: System X Kontextdiagramm") und verweise dann ausdrücklich auf diese Bezeichnung.

Achte auf eine konsistente Darstellung in deinen Diagrammen und Dokumentationen, um die kognitive Belastung deines Publikums zu verringern .⁵

Zusammenfassung

In diesem Kapitel wurden die Grundlagen der visuellen Kommunikation behandelt, auf denen du mit den übrigen Mustern und Antimustern in Teil I aufbauen kannst. Wenn du das Buch weiterliest, überlege, wie du diese Grundlagen zusammen mit den anderen untersuchten Mustern und Antimustern anwenden kannst.

Nachdem du dir überlegt hast, was deine Zielgruppe von deinem Diagramm erwartet, ist es an der Zeit, die Menge an Informationen zu überdenken, die du in deinem Diagramm darstellst. Wenn du dich auf das Minimum beschränkst, das du brauchst, um deine Botschaft zu vermitteln, wird dein Publikum sie besser verstehen.

¹ Der Detaillierungsgrad der Entwürfe für Entwicklungsteams kann umstritten sein und zu Konflikten zwischen der Entwicklung und denjenigen führen, die die Entwürfe erstellen.

² Ein Merkmal des Codes, das möglicherweise auf ein tieferes Problem hinweist.

³ C4 hat auch einige zusätzliche Diagramme, wie z.B. ein Einsatzdiagramm.

⁴ Beachte, dass die Identitäten der Datenspeicher (A, B usw.) in der gleichen Reihenfolge angeordnet sind, wie auf die Datenspeicher im Fluss des Diagramms zugegriffen wird.

⁵ Die kognitive Belastung ist der Aufwand, den eine Person betreiben muss, um über etwas nachzudenken oder zu denken.