Modulare Softwarearchitektur

Artikel#: 00068

Datum: 2021-09-20

Autor: Radim

Bevor wir mit dem Programmieren beginnen, wollen wir uns überlegen, wie wir das Programm aufteilen.

Was gewinnen wir, wenn wir das Programm richtig aufteilen?

Der Programmcode ist in mehrere kürzere Teile (Module) unterteilt. Jedes dieser Module erfüllt eine bestimmte Funktion. Die Funktion wird nur einmal im Modul programmiert, das Modul kann aber im gesamten Programm mehrfach verwendet werden. Dadurch entfällt die Notwendigkeit, denselben Code mehrmals zu schreiben oder zu kopieren, was das Schreiben, Debuggen und Ändern des Codes erleichtert.

Das Modul ist klar und leicht verständlich, da der Code nicht lang ist und nur ein Feature betrifft.

Das Modul ist gekapselt, unabhängig und erfüllt die Funktion vollumfänglich. Es ist daher auch einfach, in einem anderen Projekt zu verwenden.

Das Modul verfügt über eine klar definierte Ein- und Ausgabeschnittstelle. Mit dieser Schnittstelle verbinden wir das Modul mit dem übergeordneten Modul, das über die Eingangsschnittstelle die Sollwerte und Befehle in das Modul schreibt und über die Ausgangsschnittstelle die Istwerte und Zustände des Moduls liest.

Entsprechend benannte Eingangs- und Ausgangsmodul-Schnittstellenvariablen geben bereits die Funktion des Moduls an.

Die definierte Schnittstelle eignet sich hervorragend zum Testen der Funktionalität des Moduls während der Entwicklung und auch bei der Inbetriebnahme.

Bei Bedarf kann das Programm einfach um zusätzliche Module mit neuen Funktionen erweitert werden.

Das gesamte Programm ist strukturiert und übersichtlich.

Mehrere Programmierer können konfliktfrei gleichzeitig an einem Programm arbeiten, da jeder an einem anderen Modul arbeitet.

Die Arbeit (Programmieren, Debuggen, Testen, Dokumentieren, Simulation, Troubleshooting, Erweitern, etc.) ist effizient.

Sei vorsichtig! Eine falsch gestaltete Architektur kann später ein riesiges, unlösbares Problem sein. Wenn die Programmarchitektur schlecht ist, können selbst die besten Programmiertechniken das Ergebnis nicht retten.

© Radim-Automation, 2020–2025. Alle Rechte vorbehalten.
Die Verbreitung dieses Artikels ist mit Angabe der Quelle (Link zur Originalseite) ausdrücklich gestattet.

Verwandte vorherige Artikel:

• Denke kritisch!
• Lerne von deiner Reise!
• Warum scheitern Automatisierungsprojekte?
• Sammelt alle Anforderungen und sortiert sie!
• Wer wird operieren?
• Funktionelles und intuitives HMI
• Verwende einen nützlichen Styleguide!
• Schreibe und akzeptiere nur lesbaren Code!
• Ernenne einen Vertreter!
• HMI- und SPS-Anwendungen sollen zusammenwachsen
• Willst du damit wirklich beginnen?
• Ich sehe was, was du nicht siehst
• Mehr als nur starten und stoppen
• Sicherheit zuerst!
• Mach die richtigen Dinge und mach sie richtig!
• Definiere kontinuierlich Testszenarien und Testfälle!
• Mach es nicht schlimmer!
• Alles ist schwierig, bis es einfach wird
• Verwirkliche jede gute Idee so schnell wie möglich!
• Bleibe wachsam!
• Was braucht der Kunde?
• Enttäuscht euren Kunden nicht!
• Stelle Fragen!
• Entwickle Verantwortungsbewusstsein!
• Erledige die Dinge mit einem kleinen, motivierten Team!
• Konzentriere dich auf das Ziel!
• Überlege auf dem Papier!
• 9 Frauen können ein Baby nicht in einem Monat zur Welt bringen
• Verstecke kein Problem!
• Überprüfe das Ergebnis!
• Halte es einfach!
• Verlass kein Arbeitspaket halbfertig!
• Erfolg ist kein Zufall
• Wähle das richtige Werkzeug!
• Entwicklung ist Evolution
• Folge der Vision!
• Vernachlässige und überspringe keinen Schritt!
• Transparenz und Zuverlässigkeit
• Von einer Idee zu einem konsistenten System

Verwandte nächste Artikel:

• Maschinenmodularisierung
• Erkenntnisse aus einem abgeschlossenen Projekt sind unbezahlbar
• Variablennamen
• Wahl der Programmiersprache
• Visuelle Modellierung
• Dokumentationsprobleme
• Sicherheitsrelais versus Sicherheits-SPS
• Designüberlegungen für effektive HMIS
• Klare Signale
• Ereignislogger als allererste im Programm implementierte Funktion
• Diagnosetools
• Mein Chef war ein Held
• Versionskontrollsystem
• SPS-Netzwerkdiagramm
• Halte die Dokumentation während des gesamten Projekts auf dem neuesten Stand
• Pflege Ordnung im Programmkode
• Mache Backups, nehme kleine Änderungen vor und teste viel
• Traum von einem plattformunabhängigen SPS-Programm
• Halte alles, was du brauchst, zusammen
• HMI - Habt einen konsistenten Stil
• Auswahl eines HMI-Displays
• Die falsche Illusion des schnellen Fortschritts
• HMI-Layout und richtige Displaygrösse
• HMI-Layout-Design
• HMI-Navigation
• HMI – Zurück- und Vorwärts-Navigationstasten
• HMI - Verstecke nichts
• Was macht eine HMI intuitiv?

Kommentar#: 00001

Datum: 2021-09-25

Benutzer: Radim

Ich sehe eine grosse Ähnlichkeit zwischen einem Hausbauprojekt und einem Projekt der industriellen Maschinenautomatisierung.

1. Wir müssen eine Vorstellung davon bekommen, was das Ergebnis sein wird, wofür es verwendet wird und wie gross es sein wird.

2. Wir müssen alle notwendigen Anforderungen zusammentragen.

3. Je nach Grösse des Gebäudes / Programms ist es notwendig, ein ausreichend grosses Grundstück / eine ausreichend leistungsfähige SPS auszuwählen.

4. Es ist notwendig, eine geeignete Architektur und Pläne / SW-Architektur und Konzept zu entwerfen.

5. Wir verbinden technische Netzwerke zu dem Grundstück unter Berücksichtigung der Verfügbarkeit am jeweiligen Standort. / Andere elektrische Komponenten wählen wir entsprechend ihrer Kompatibilität mit der ausgewählten SPS aus.

6. Wir müssen ein solides Fundament für das Haus bauen. / Wir müssen eine zuverlässige unterste Programmschicht programmieren (Hardware-Abstraktionsschicht und allgemeine Funktionen).

7. Dann können wir den Rest nach den Anforderungen und Plänen bauen.

8. Stellt jetzt jemand eine neue Anforderung, kann diese nur in das Gebäude / Programm eingebaut werden, wenn diese Anforderung der vorgeschlagenen Architektur entspricht.

9. Bei falscher Architektur oder schlechten Fundamenten kann selbst der beste Maurer / Programmierer das idealisierte Gebäude / Programm nicht bauen.

Kommentar#: 00002

Datum: 2021-10-04

Benutzer: Radim

Sogar eine einfache Maschine oder Anlage kann so komplex entworfen und programmiert werden, dass deren Diagnose und Erweiterung nur mit extremem Aufwand und einem hohen Risiko der Einführung neuer ungewollter Fehler möglich ist.
Glaubst du?

Kommentar#: 00003

Datum: 2021-10-19

Benutzer: Radim

Es ist besser, ein modulares Programm zu schreiben, das in Zukunft leicht erweiterbar ist, als ein grosses monolithisches Programm, das alle möglichen Funktionen enthält.
Ein grosser monolithischer Programmblock ist schwer zu modifizieren, da er eine grosse Anzahl von Abhängigkeiten und "versteckten" Regeln enthält.

Kommentar#: 00004

Datum: 2021-10-20

Benutzer: Radim

Die Aufteilung des Maschinenprogramms in Module kann auch für Visualisierung sinnvoll sein. In der Visualisierung ist es manchmal notwendig, mehrere Ansichten zu haben. Eine modulare Ansicht ist eine Ansicht, die strukturiert Informationen über die gesamte Maschine anzeigt.

Kommentar#: 00005

Datum: 2021-10-20

Benutzer: Radim

Bei entsprechend modularem Aufbau der Maschinenelektronik ist es möglich, die Maschine stückweise zu testen und in Betrieb zu nehmen.

Kommentar#: 00006

Datum: 2022-07-28

Benutzer: Radim

"Durch den zunehmenden Trend, maschinenbauliche Anlagen möglichst flexibel zu gestalten, ist es unabdingbar geworden, bestehende Programme so zu verändern, dass sich modulare Maschinenkonzepte auch in der Software widerspiegeln. Damit wird die Modularisierung zum Leitprinzip für die Gestaltung der Programme der Zukunft. Modularisierte Software umfasst Module, die als unabhängige Einheiten voll funktionsfähig und getestet sind, aber innerhalb verschiedener Maschinen zu einer einzigen Funktionseinheit kombiniert werden können."
- Michael Braun and Wolfang Horn. Publicis Pixelpark Erlangen (2017). Object-Oriented Programming with SIMOTION.

Kommentar#: 00007

Datum: 2023-06-08

Benutzer: Radim

"Investitionen in gute Codequalität und gute Architektur sind nachhaltige Investitionen. Über 80% der Entwicklungs-Arbeiten sind Wartungsarbeiten sowie Änderungen an bestehendem Code. Prof. Niklaus Wirth meinte einmal, dass SW nicht für den Compiler geschrieben wird, sondern für Menschen die den Code warten müssen. Stellt sich die Frage nach „quick and dirty“, ist die Tragbarkeit der «technischen Schuld» mit zu berücksichtigen, denn irgendwann wird die Schuld untragbar oder so gross, dass ein «Neubeginn» billiger wird. Versicherungstechnisch spricht man hier von einem «Total-Schaden». Oft wird bei «quick and dirty Lösungen» immer wieder im gleiche Stil weiter «gewurstelt». Neben bestehenden schlechten Codestellen fallen weitere «Spaghetti – Zeilen» nicht mehr auf, ein Freipass…

So beginnt ein Teufelskreis, denn mit der wachsenden «technischen Schuld», verlangsamt sich –wegen unlesbarem und schlechtem Code – auch die Entwicklungsgeschwindigkeit. Dies verzögert das Fertigstellen neuer Features und das Projekt muss mit explosiv steigenden Opportunitätskosten leben."
- https://blog.noser.com/kennen-sie-ihre-technische-schuld-wir-unterstuetzen-sie-bei-der-rueckzahlung/

Kommentar#: 00008

Datum: 2023-09-27

Benutzer: Radim

"Indem wir das Design des Codes kontinuierlich verbessern, machen wir es immer einfacher, damit zu arbeiten.
Dies steht in krassem Gegensatz zu dem, was normalerweise geschieht: wenig Refactoring und viel Aufmerksamkeit, um schnell neue Funktionen hinzuzufügen.
Wenn man sich die hygienische Angewohnheit angewöhnt, kontinuierlich zu refaktorisieren, wird man feststellen, dass es einfacher ist, den Code zu erweitern und zu pflegen."

Übersetzt von:
- Joshua Kerievsky. Addison-Wesley (2004). Refactoring to Patterns.

Kommentar#: 00010

Datum: 2024-01-05

Benutzer: Radim

Lasst uns die Dinge beschleunigen!

Ein Mann braucht eine Stunde, um ein 1 m tiefes, 1 m breites und 1 m langes Loch zu graben. Wie viel Zeit braucht man, wenn man 10 Männer einsetzt?

ChatGPT: "Wenn ein Mann ein Loch von 1 m Tiefe, 1 m Breite und 1 m Länge in einer Stunde graben kann und 10 Männer gleichzeitig arbeiten, kann man die Zeit durch die Anzahl der Männer teilen, um die Gesamtzeit zu ermitteln, die die Gruppe für die Aufgabe benötigt.

Es würde also 1 Stunde / 10 Männer = 0,1 Stunden (oder 6 Minuten) dauern, bis die Gruppe von 10 Männern das Loch gegraben hat.

Sind Sie mit der Antwort von ChatGPT einverstanden?