Der Weg zur Embedded World 2021: Teil 4

Anmerkung der Redaktion: In Episode 1 dieser Serie aus fünf Beiträgen im Vorfeld der Embedded World 2021, wurde ein Überblick darüber gegeben, was die Embedded World ist. In Episode 2 hat Randall seine Kenntnisse der Programmiersprache C aufgefrischt. Episode 3 konzentriert sich darauf, wie die Verwendung der objektorientierten Programmierung Komplexität reduzieren kann. In dieser Folge, Episode 4, wird gezeigt, dass das grundlegende Maß für gutes Design seine Fähigkeit ist, bei veränderten Anforderungen neu konfiguriert werden zu können, ohne dass die Bausteine neu implementiert werden müssen. Im letzten Blog, Episode 5, wird der ständig wachsende Speicherbedarf von Betriebssystemen hinterfragt und die Systemdekomposition vor Randalls Keynote-Präsentation auf der Embedded World 2021 angesprochen.

Bisher habe ich behandelt, wie sich Software zu dem entwickelt hat, was sie heute ist - objektorientiert - und ich habe beschrieben, wie die Objektorientierung eine Analogie zur Elektronik hat. Das objektorientierte Denken bietet eine Möglichkeit, Ersatzmodelle von realen Dingen (d.h.: Objekten) zu erstellen. Ich habe auch über die Eigenschaften der objektorientierten Programmierung (OOP) gesprochen und darüber, wie man die Qualität solcher Modelle beurteilt, aber ich habe nicht darüber gesprochen, wie man diese Modelle erstellt. Dies hat damit zu tun, wie man ein System in sinnvolle Module und Bausteine zerlegt. Dies ist ein Bereich der Designmethodik, über den bereits in den frühen 1970er Jahren geschrieben wurde und einige dieser Lektionen tauchen heute wieder auf.

Die beliebteste Art, ein System zu partitionieren, ist sicherlich die nach Funktionen. Dies besteht darin, alle in einem System benötigten Funktionen als Bausteine aufzulisten und Entwickler mit der Implementierung dieser Bausteine zu beauftragen. Es stellte sich heraus, dass dies nicht der beste Weg ist, ein System zu entwerfen. Es hat viele Fallstricke, die zu Inflexibilität und Mehrarbeit für Entwickler führen. Ein durch funktionale Dekomposition entworfenes System funktioniert, aber es gibt einen besseren Weg. Es stimmt, dass die andere Methode zu Beginn schwieriger ist und es nicht einfach ist, sich einen Überblick zu verschaffen. Sie kostet zwar im Vorfeld mehr Zeit, aber im Nachhinein verläuft die Entwicklung reibungsloser und führt zu einem System, das sich leichter an Änderungen anpassen lässt.

David L. Parnas, Quelle: Wikipedia (https://en.wikipedia.org/wiki/David_Parnas)

David Parnas, von der Carnegie-Mellon University, schrieb 1971 mehrere Abhandlungen über Systemdesign und Modularität. Diese Arbeiten haben dazu beigetragen, die Begriffe Kopplung und Kohäsion zu etablieren, die ich in einem früheren Beitrag erwähnt habe. Eine dieser Abhandlungen hieß „Information Distribution Aspects of Design Methodology“ und wurde im Februar 1971 geschrieben. Es handelt sich um eine kurze Abhandlung, die aber sehr gründlich beschreibt, was eine Entwurfsmethodik ist. Er sagte: „Der Fortschritt in einem Design ist durch Entscheidungen gekennzeichnet, die einige Möglichkeiten der Systemstruktur eliminieren“. Er sagt, dass nach der Eliminierung von Möglichkeiten eine Begründung für nachfolgende Entscheidungen geschaffen wird, und er gibt Beispiele, die seine Behauptung unterstützen. Diese Methoden schaffen jeweils eine Annäherung an eine Lösung.

Er identifizierte drei Ansätze:

1. Berücksichtigung von „guten“ externen Überlegungen

2. Verkürzung der Zeitspanne zwischen Beginn und Abschluss eines Projekts

3. Erschaffung eines leicht zu ändernden Systems

Ansatz 1 bezieht sich auf einen „Top-Down“-Ansatz. Ansatz 2 führt dazu, dass Entscheidungen über die Modularisierung getroffen werden, die möglicherweise nicht die volle Auswirkung auf die endgültige Nutzbarkeit des Produkts berücksichtigen, aber es bringt die Entwickler dazu, schneller zu entwickeln. Ansatz 3 identifiziert die Faktoren, die sich wahrscheinlich am wenigsten ändern werden, mit dem Ergebnis, dass die allgemeinsten Informationen zuerst verwendet werden.

Er argumentiert, dass ein Top-Down-Ansatz zu Systemen führen kann, die später schwieriger zu verändern sind, einfach weil das Entscheidungskriterium externe Faktoren mehr begünstigt als diejenigen, die die Veränderung bewirken. Er schließt diesen Abschnitt seines Aufsatzes mit der Feststellung, dass die Reihenfolge der Entscheidungen, die in diesen Ansätzen getroffen werden, inkonsistent ist und es daher unmöglich macht, alle gleichzeitig zu erfüllen. Diese Position wird in seinem nächsten Papier aufgegriffen, das ich vorstellen werde, aber ich möchte zunächst meine Kommentare zu diesem ersten Papier von ihm abschließen.

Ich finde seine Beschreibungen von guten Programmierern interessant. Er sagt: „Ein guter Programmierer nutzt die ihm gegebenen verwertbaren Informationen!“ Er fährt fort, dass ein guter Programmierer clever sein wird und möglicherweise Informationen verwendet, die nicht dokumentiert sind, und dies bedeutet, dass eine Änderung in einem Block Änderungen in anderen Blöcken erfordert. Dies ist die Idee der Konnaszenz, die ich in meinem letzten Beitrag erwähnt habe, und sie ist mit Ansatz 3 unvereinbar. Das Fazit dieses ersten Papiers ist, dass das Verbergen von Informationen gut ist - das bedeutet, dass Systemdesigner Designinformationen auf einer „Bedarfsgrundlage“ preisgeben sollten, wie Parnas es ausdrückt.

Parnas schrieb daraufhin im August 1971 ein weiteres Papier mit dem Titel „On the Criterion to Be Used in Decomposing Systems into Modules“. Dieses Papier hat viel Bekanntheit erlangt und erlebt gerade eine kleine Renaissance. Es ist dieses Papier, in dem er dafür plädiert, Systeme auf der Basis der Wahrscheinlichkeit von Veränderungen zu entwerfen - d.h.: Ansatz 3 aus seinem früheren Papier.

Sein Ziel war es, die Flexibilität und Verständlichkeit des Systems zu verbessern und gleichzeitig die Gesamtentwicklungszeit zu verkürzen, und er illustriert den Erfolg mit Beispielen. Indem man den Code auf der Basis von Informationsausblendung modularisiert, modularisiert man ein System auf der Basis des Änderungsmanagements. Änderungen werden auf weniger Module isoliert, was bedeutet, dass es einfacher ist, Systemänderungen und Rekonfigurationen vorzunehmen, wenn sich die Anforderungen ändern. Unabhängig davon, ob Funktions- oder Änderungsdekomposition verwendet wird, kann ein System funktionieren, aber durch die Sicherstellung einer hohen Kohäsion auf der Basis des Verbergens von Informationen wird ein System flexibler, umfassender und schneller entwickelt.

Betrachten Sie den Fall, dass ein bekanntes Element einer gegebenen Struktur im Speicher gespeichert ist. Wenn ein System funktional zerlegt wird, können beliebige oder alle Module auf ihm arbeiten. Wenn die Struktur geändert wird, müssen alle Module, die darauf zugreifen, geändert werden. Wenn diese Struktur jedoch von einem Modul verwaltet wird, das für die Bereitstellung des Zugriffs verantwortlich ist, könnte die Struktur geändert werden, ohne dass jedes Modul, das Zugriff darauf benötigt, geändert werden muss. Der Punkt ist, dass der Entwickler bei dieser Methodik schon am Anfang identifiziert, was sich wahrscheinlich ändern wird. Jede Methodik erzeugt die gleiche Funktionalität, aber es ist die Modularität, die sich unterscheidet. Parnas ist der Meinung, dass eine Modularität, die auf Veränderung basiert, Designentscheidungen besser offenlegt als eine, die auf Funktion basiert, und dadurch ein System leichter nachvollziehbar macht.

Die Modularisierung auf der Basis von Informationsausblendung ist nicht ohne Tücken. Parnas weist darauf hin, dass Systeme, die auf diese Weise entworfen wurden, ineffizient sein können, aber er argumentiert, dass es immer wichtiger wird, Informationen zu verbergen, je größer ein System wird. Ich werde in meinem letzten Beitrag im nächsten Monat auf die Gefahren eingehen.

Ganz grundsätzlich gilt: Um die Wiederverwendung von Funktionalität zu verbessern, muss die Schnittstelle zu dieser Funktionalität so wenig Informationen wie möglich preisgeben. Wie Einstein sagte: „Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher“. In unserem Fall müssen wir „Alles“ durch „Die Schnittstelle“ ersetzen. Diese Aufgabe ist gut geeignet für den Embedded-Ingenieur. Der Embedded-Engineer ist in vielen Techniken geschult, was ihm die Möglichkeit gibt, auf jeder Ebene eines Designs zu arbeiten, im Vergleich zu jemandem, der nicht geschult ist. Das Designs des Ingenieurs sollten so einfach wie möglich zu verwenden sein, wenn es von einer möglichst großen Anzahl von Anwendern (d.h.: Kunden) genutzt werden sollen.

Quelle: https://rightingsoftware.org/

Wie ich bereits erwähnt habe, erlebt die Arbeit von Parnas gerade eine kleine Renaissance. Ich lade jeden, der mehr erfahren möchte, ein, Parnas' Papiere zusammen mit einem Buch mit dem Titel „Righting Software“ von Juval Löwy zu lesen.

Löwy lobt Parnas für seinen Ansatz, der darin besteht, ein System zu entwerfen, indem man es unter Berücksichtigung der Volatilität potenzieller Änderungen zerlegt und diese potenziellen Änderungen in Bausteinen kapselt. Das gewünschte Verhalten des Systems wird dann als Interaktion zwischen diesen Bausteinen implementiert. Ein erfolgreiches Design ist eines mit dem kleinsten Satz von Bausteinen, die alle Anwendungsfälle erfüllen. Dies ist leicht gesagt.

Löwy sagt, dass Sie diesen Satz erstellen, indem Sie die Kernanwendungsfälle kennen. Er fügt hinzu, dass es fast nie viele davon gibt, etwa 1 bis 3, so dass in der Regel weniger als ein Dutzend resultierende Komponenten vorhanden sind. Die Anzahl der Zusammensetzungen und Wechselwirkungen von 12 Elementen ist enorm. Ich denke an die Vielfalt von Liedern, die aus 12 Noten auf einem Musikinstrument gemacht werden können. Es gibt die Reihenfolge der Töne und das Timing der Töne, daher denke ich, dass er Recht hat.

Er fährt fort, dass ein Mensch von vor 200.000 Jahren keinen anderen Anwendungsfall hatte als wir heute. Dieser Anwendungsfall ist das Überleben, doch die Architektur, die dies durch Jagen und Sammeln ermöglichte, ist dieselbe Architektur (d.h.: verwendet dieselben Komponenten), die es einem Softwareentwickler heute ermöglicht, seinen Lebensunterhalt zu verdienen. Er argumentiert, dass ein Elefant und eine Maus im Grunde gleich aufgebaut sind, aber es ist ihr detailliertes Design, das unterschiedlich ist. Das ist ein überzeugendes Argument.

Das grundlegende Maß für ein gutes Design ist also seine Fähigkeit, bei veränderten Anforderungen neu konfiguriert zu werden, ohne die Bausteine neu implementieren zu müssen. Eine erfolgreiche Dekomposition befriedigt alle Anforderungen: vergangene, zukünftige, bekannte und unbekannte. Das ist schwerer Stoff und es lohnt sich, ihn zu studieren.

In meinem letzten Beitrag werde ich, wie bereits erwähnt, ein Problem beschreiben, das wir geschaffen haben, als wir es mehr Menschen ermöglicht haben, die von uns entwickelten Funktionen zu nutzen, aber ich werde argumentieren, dass dies der Preis ist, den wir für breitere Märkte zahlen.