AT -- Konstruktion - software

AT -- Konstruktion
1
AT -- Konstruktion
...................................
Summary:
Die Konstruktion beschreibt die modulare Gestaltung eines Softwaresystems, d.h. seinen Aufbau
aus Bausteinen und deren Zusammenspiel. Die Konstruktion abstrahiert von Details der
Programmierung, nimmt aber auf grundsätzliche Gegebenheiten der Programmier- und
Betriebsplattform Rücksicht.
4 Architektursicht Konstruktion
Ein Softwaresystem aus der Sicht der Anwendung zu betrachten und zu bewerten ist naheliegend, ebenso der Blick
auf seine programmtechnische Realisierung: Die Anwendung ist der Zweck des Systems und der Programmcode
seine Verwirklichung. Aber was ist die Konstruktion? Wie bei jedem technischen Produkt liegt auch bei Software
der Realisierung eine Überlegung zugrunde, wie sie hergestellt – wir sagen: konstruiert – wird. Die Konstruktion ist
die gedankliche Brücke zwischen Anwendung und Programm. Sie beschreibt die modulare Gestaltung eines
Softwaresystems. Dessen Architekt fängt von beiden Seiten das Denken und Konstruieren an: vom fachlichen
Problem her und von der technischen Plattform, auf die er die Anwendung zu bauen hat.
Die Architektursicht Konstruktion sollte unabhängig sein von Programmiertechniken, die zur Realisierung der
Software eingesetzt werden. Dies ist Sache der Architektursicht Programm.
4.1 Modularität
Der Begriff Modularität bezeichnet die Sicht auf die modulare Gestaltung eines technischen Systems, d.h. seinen
Aufbau aus Bausteinen und deren Zusammenspiel. Im Falle von Softwaresystemen sind das Module und
Komponenten, (Unter)Programme und Makros, Dateien und Datenbanken, (Betriebssystem)Prozesse, etc. Sie
benutzen einander in unterschiedlicher Weise, etwa durch Aufrufe, Nachrichtenaustausch, Datenzugriffe. In diesen
Benutzungsbeziehungen drückt sich das dynamische Zusammenwirken der Bausteine aus.
Jedes Softwaresystem hat eine irgendwie geartete Struktur. Was aber macht eine gute Struktur aus, was sind
Kriterien einer guten Modularität? Wie lässt sich damit die Komplexität beherrschen, die großen Softwaresystemen
zwangsläufig innewohnt? Nach [Denert 91], Seite 213: „Allgemein ausgedrückt, zeichnet sich eine gute
Modularisierung durch hohe Kohäsion (interne Bindung) und geringe Kopplung (externe Bindung) der Module aus.“
Anders ausgedrückt: Ein Baustein realisiert eine bestimmte Funktionalität, diese ist nicht über mehrere Bausteine
verteilt; er kommuniziert mit anderen Bausteinen über schmale Schnittstellen. Das ist in den meisten technischen
Gebieten selbstverständlich. So sind beispielsweise im System Auto Motor und Getriebe klar separierte Einheiten,
die in wohldefinierter Weise zusammenarbeiten. In der Software ist das oft nicht so klar. Der Code einer
zusammengehörenden Funktionalität kann weit verstreut und somit die Schnittstelle zu anderen Bausteinen
unübersichtlich sein.
Zur Gestaltung von Software-Architektur besonders gut geeignet ist die Methode der Objektorientierung mit ihrem
Grundkonzept, zusammengehörige Daten und die auf ihnen operierenden Funktionen zusammenzufassen in einer
Einheit, einer Klasse, einem Modul. Man spricht auch davon, dass die Daten von den Funktionen gekapselt werden,
der Zugriff auf sie also nur über die Funktionen möglich ist (Datenkapselung, data encapsulation). Dieses
Modulkonzept hat seinen Ursprung in zwei miteinander korrespondierenden softwaretechnischen Entwicklungen:
• Erstens in dem Anfang der 1970er Jahre von Parnas, Guttag und anderen propagierten Konzept der
Datenabstraktion. Parnas hat damals das Geheimnisprinzip (information hiding) formuliert: Man muss die interne
programmtechnische Struktur der Daten nicht kennen, um das Modul nutzen zu können. Sie wird nach außen
hinter dessen Funktionen verborgen, die somit eine abstrakte Sicht auf die Daten bieten. Man spricht deshalb von
AT -- Konstruktion
Datenabstraktionsmodulen und von abstrakten Datentypen, für die Guttag die Methode der algebraischen
Spezifikation entwickelt hat.
• Zweitens in der objektorientierten Programmierung, beginnend mit Simula in der zweiten Hälfte der 1960er Jahre,
die heute das dominierende Programmierparadigma ist. Die Datenabstraktion findet sich darin wieder in Form der
Klasse mit ihren Variablen und Methoden.
Diese beiden zunächst programmiertechnischen Entwicklungen sind so grundlegend, dass sie ein prägendes Konzept
sind für die Konstruktionssicht auf die Software-Architektur.
Wie erzielt man nun gute Software-Modularität? Es gibt dafür ein Repertoire an Prinzipien, Methoden, Techniken
und Darstellungsformen:
• Da ist zuvorderst die schon genannte Objektorientierung.
• Vor allem schafft man gute Modularität durch geeignete Abstraktionen (separation of concerns) mit gut
gewählten und präzise definierten Begriffen aus der Anwendungswelt oder der systemtechnischen Umgebung, je
nachdem um welche Art Baustein es geht.
• Ein probates Mittel der Strukturierung besteht darin, Softwareschichten zu bilden.
• Es gibt ein umfangreiches Repertoire an Entwurfsmustern (design patterns), initiiert durch das Buch von [Gamma
et al 95]. Diese Muster beschreiben auch exemplarisch die technische Umsetzung. Für die Konstruktion
interessiert uns nur ihre Entwurfsidee.
• Querschnittskonzepte für Fehlerbehandlung, Sicherheit etc. sollten durchgängig und einheitlich eingesetzt
werden.
• Eine gut gestaltete und gut lesbare Dokumentation der Software und ihrer Architektur trägt zwar nur mittelbar zur
Modularität bei, ist jedoch für ihr Verständnis notwendig und nützlich und spiegelt ihre Güte wider: (un)klare
Dokumentation – (un)übersichtliche Modularität.
4.2 Konzepte der Konstruktion
Im Kontext der Konstruktion sprechen wir davon, dass ein Software-System aus Modulen aufgebaut ist, die
ihrerseits durch Schnittstellen definiert sind. Zudem benutzen wir den Begriff Komponente, um Zusammenfassungen
von Modulen zu bezeichnen.
Die Abbildung
veranschaulicht, wie diese Begriffe
zueinander stehen und zeigt, dass ein
System aus Komponenten aufgebaut
ist, evtl. über mehreren Ebenen, und
letztlich aus Modulen besteht. Eine
derartige Konstruktionszeichnung stellt
die statische Struktur der Software dar,
wie sie im Quellcode realisiert ist oder
werden soll. Sie zeigt nicht ihr
dynamisches Verhalten. Dafür gibt es
in der Konstruktion selbstverständlich
auch Darstellungen, etwa in Form von
Daten- und Kontrollfluss-Diagrammen,
Zustandsautomaten u.ä.m.
Diese Begriffe werden in den
folgenden Abschnitten erläutert. Man
2
AT -- Konstruktion
beachte, dass wir uns dabei nicht auf Konzepte bestimmter Programmiersprachen beziehen. Diese sind der →
Architektursicht Programm vorbehalten.
4.2.1 Modul
In der Konstruktion geht es um den modularen Aufbau eines Softwaresystems. Wie das Wort modular schon
andeutet, ist das Modul ein zentrales Konzept der Konstruktion.
Ein gut gestaltetes Modul realisiert eine (und nur eine) bestimmte Funktionalität, es ist auf einen Sachverhalt
(Know-how) konzentriert und nicht ein Sammelsurium unterschiedlicher Aspekte. Anders und informatisch
ausgedrückt: Ein Modul ist eine untrennbare Einheit aus Funktionen und Daten; Veränderungen der Daten sind nur
über die Benutzung der Funktionen möglich.
Das erwähnte Geheimnisprinzip hat in der Konstruktion keinen Platz – es kommt erst in der Programmsicht zum
Tragen –, denn es gibt keine programmtechnisch bedingten Datenstrukturen zu verbergen, wie es etwa get()-und
set()-Methoden in Programmen tun. Die Konstruktion kennt sie nicht, sie ist vielmehr ein offenes Buch: Die
Daten(strukturen), die hier eine Rolle spielen, stammen aus der Anwendungssicht, es sind durchweg Attribute von
Anwendungsobjekten.
4.2.1.1 Modulschnittstelle
„The connections between modules are the assumptions which the modules make about each other.” Diese
historische Formulierung von Parnas (IFIP-Kongress 1971) erscheint vage, charakterisiert jedoch, worum es geht:
um die Gestaltung der Beziehungen – der Schnittstellen – zwischen den Modulen eines Softwaresystems. Sie prägen
seine Architektur; seine Funktionalität und Leistung entstehen in der Interaktion seiner Bausteine. Die Kunst der
Konstruktion liegt in der Gestaltung der Schnittstellen.
Ein Modul bietet seine Leistungen nach außen, d.h. anderen Modulen, über Schnittstellen an, durch deren Festlegung
das Modul spezifiziert (definiert) ist. Eine Schnittstelle besteht aus einer oder mehreren Funktionen mit deren
Parametern. Bei Anwendungsfunktionen sind letztere Attribute der Anwendungssicht.
Module können mehrere Schnittstellen haben, derart dass Funktionen zu Gruppen zusammengefasst werden, die
spezialisiert sind für unterschiedliche Nutzungsweisen durch andere Module. Module bieten (exportieren) ihre
Schnittstellen anderen Modulen an und nutzen (importieren) ihrerseits die Schnittstellen anderer. Die Differenz
zwischen den Leistungen, die Module importieren, und jenen, die sie exportieren, ist ihre Wertschöpfung.
Damit ein Modul benutzt werden kann, muss seine Schnittstelle bekannt sein. Sie – und damit der Modul an sich –
ist definiert (spezifiziert) durch Syntax und Semantik, also eine formale Festlegung, wie die Schnittstelle zu benutzen
ist, und eine inhaltliche Definition des Effekts, den die Benutzung zur Folge hat. Dieser Effekt kann sein das
Speichern, Berechnen und Bereitstellen von Daten sowie das Ausführen bestimmter Aktionen.
Die Spezifikation der Schnittstelle sollte möglichst präzise und verständlich formuliert und dokumentiert sein, damit
der Benutzer eine klare Vorstellung davon bekommt, was er von dem Modul zu erwarten hat und nicht auf
Mutmaßungen angewiesen ist. Man spricht auch davon, dass die Spezifikation eine Art Vertrag ist zwischen
nutzendem und genutztem Modul.
Module können auf zweierlei Weise kommunizieren: Frage & Antwort oder einseitige Mitteilung. Dabei ist zu
beachten, ob ein Modul, das einem anderen dient, zustandslos ist oder ein Gedächtnis hat, in dem der Zustand der
bisherigen Kommunikation vermerkt ist. Eine spezielle Form zustandsbehafteter Module sind solche, die ein
Protokoll, also die Regeln zur Kommunikation zwischen Systemen, realisieren.
Es gibt verschiedenartige Kommunikationskanäle, über die Module interagieren können:
• Kettenartige Weitergabe von Dateien und zugehörigen Verarbeitungsanweisungen (Batches)
• Prozedur-/Unterprogrammaufruf innerhalb eines Lademoduls
3
AT -- Konstruktion
4
• entfernter Prozeduraufruf (remote procedure call) über die Grenzen von Betriebssystemprozessen oder gar
Rechnern hinweg (z.B. CORBAE, SOAP, rmi, REST)
• Nachrichten (uni- und bidirektional), Subskriptionsmechanismen
• Ereignis/Signal, das eine Modulfunktion aktiviert
• Austausch über die Veränderung gemeinsam genutzten Speichers (shared Memory, Datenbank)
Eine ausführliche Darstellung zu diesem Thema findet sich bei [Taylor].
Diese Kanäle haben unterschiedliche Reichweiten, von ganz nah (innerhalb einer Objektcodeeinheit) bis ganz weit
(über das Internet), sie können innerhalb des eigenen Rechnersystems bzw. -netzes liegen oder dieses mit anderen
Systemen verbinden. Sobald die Kommunikation das eigene System verlässt, ist Vorsicht geboten, denn die
Kontrolle liegt dann anderswo. Techniken zur Sicherung der Kommunikation können nötig werden, damit die zu
übertragenden Daten nicht verfälscht oder missbraucht werden können.
4.2.1.2 Benutzungsbeziehungen
Ein Modul wird mittels seiner Funktionen benutzt. In der Konstruktion kann es jedoch mitunter genügen,
Benutzungsbeziehungen auf der Ebene von Modulnamen festzulegen. Auf einer Übersichtsebene und bei freien
textuellen Beschreibungen sind Modulnamen zur Charakterisierung der beteiligten Partner ausreichend. Beispiel:
...................................
"Beim Anlegen eines neuen BuchTitels wird die nächste freie Nummer von der
ISBN-Verwaltung besorgt".
Bei semi-formalen Konstruktionsbeschreibungen wird man Modul-Benutzungen durch die Angabe von
Funktionsnamen präzisieren und Parameterübergaben andeuten:
...................................
"Die Funktion BuchTitel.anlegen() benutzt
ISBNVerwaltung.nächsteFreieISBN(BuchTitel.Sachgebiet)".
Wie derartige Notationen unter dem Gesichtspunkt der Präzision, Informationsdichte und Lesbarkeit bewertet
werden, ist eine Ermessensfrage. Das zusätzliche Detail (die Vergabe einer ISBN hängt offenbar vom Sachgebiet des
BuchTitels ab) hätte man auch in der freien sprachlichen Formulierung unterbringen können. Abzuraten ist von
Worten wie "this" oder "self", um das handelnde Modul zu referenzieren. Derartige Schlüsselwörter aus dem
Begriffsapparat der objektorientierten Programmierung passen nicht in die sprachliche Ebene der Konstruktion.
Possesivpronomina drücken den Sachverhalt elegant aus und machen zudem klar, dass Module als selbstständig
handlungsfähige Wesen aufgefasst werden können. Hier ein Formulierungsvorschlag:
...................................
Der BuchTitel fragt unter Angabe 'seines' Sachgebiets bei der ISBNVerwaltung nach
der nächsten freien Nummer.
Ein Problem des Erzählstils sei nicht verschwiegen: Allzuleicht passiert es, dass man in Usecase-artige Schilderung
von Prozessabläufen gerät und dabei Informationen an der falschen Stelle landen:
...................................
"Der Buchtitel fragt die ISBNVerwaltung nach der nächsten freien Nummer. Diese verwaltet
aus historischen Gründen spezielle Nummernkreise je Sachgebiet."
Der Umstand, dass die ISBNVerwaltung "Nummernkreise" kennt und über Funktionen verfügt, solche
Nummernkreise einzurichten und Sachgebieten zuzuordnen, hat nichts bei der Beschreibung des BuchTitels zu
suchen. Sie gehört zum Modul ISBNVerwaltung.
AT -- Konstruktion
4.2.2 Komponente
Der Begriff Komponente hat im IT-Sprachgebrauch keine scharf umrissene Bedeutung, er wird meist vage für alles
Mögliche gebraucht, das ein strukturbildendes Element sein soll. Dennoch benutzen auch wir dieses Wort, und zwar
in folgendem Sinn: Eine Komponente ist eine Gruppierung (Zusammenfassung, Menge) von Modulen oder
Komponenten, die hauptsächlich dem Aufzeigen von Zusammenhängen und somit auch der Dokumentation dient,
siehe Abbildung Konzepte und Begriffe der Perspektive Konstruktion.pptx.
Solche Zusammenhänge können sein:
• Schichtenbildung (Zugriffs-/Treiberschicht, Anwendungslogik (-kern), Benutzer-Schnittstelle
• mehrere Module, die in einer sachlichen Beziehung stehen, z.B. Verwalter und ihre Objekte, etwa Konto und
Kontoverwalter
Ein Modul kann in mehreren Komponenten enthalten sein. Es ist dann wie eine Kopie zu sehen, nicht jedoch zu
verwechseln mit dem Erzeugen eines Objekts einer Klasse, wie dies in der objektorientierten Programmierung zur
Laufzeit geschieht.
4.2.2.1 Komponentenschnittstelle
Die Schnittstelle einer Komponente besteht in der Regel aus einer Teilmenge der Funktionen ihrer Module, denn der
Sinn ihr ist es, eine größere Funktionalität modular zu strukturieren. Einige Module werden nur komponentenintern
verwendet, ihre Funktionen werden nach außen nicht (oder nur teilweise) angeboten. Sie erscheinen wie
"Subunternehmer" der Komponente.
4.2.3 System
Mit dem Begriff (Software-) System bezeichnen wir ein eigenständiges Ganzes, das auf die Eingabe von
Informationen mit einer wohldefinierten Reaktion antwortet, indem es Informationen speichert, transformiert und
ausgibt. Es dient Menschen bei der Informationsgewinnung und -verarbeitung oder der Steuerung von Maschinen
bzw. Geräten. Ein Subsystem, auch Teilsystem genannt, ist ein eigenständiges System, das jedoch im Verbund eines
umfassenderen Systems läuft.
4.2.3.1 Systemschnittstelle
Systemschnittstellen sind von anderer Art als Modul- und Komponentenschnittstellen, denn sie dinen der
Kommunikation mit der Außenwelt. Dabei ist wiederum zu unterscheiden zwischen der Schnittstelle zu einem
menschlichen Benutzer – Benutzeroberfläche genannt – und zur technischen Umgebung eines Systems, etwa in
Form von Sensoren und Aktoren.
4.3 Aspekte der Konstruktion
(davon gibt es wohl noch mehr, als im Folgenden aufgeführt)
5
AT -- Konstruktion
6
4.3.1 Fachlicher Nutzen und technisches Fundament
Die Konstruktion geht primär von den fachlichen Inhalten und Anforderungen des Systems aus, den
Anwendungsfunktionen, wie sie vom Auftraggeber definiert sind und vom Anwender benutzt werden. Sie stellen die
Anwendungssicht dar. Die Konstruktion definiert dafür fachliche Module. Diese sind spezifisch für das jeweilige
System; sie werden vollständig, präzise und möglichst unabhängig von der technischen Umsetzung beschrieben.
Die Anwendungsfunktionen bedürfen eines Fundaments von Basisfunktionen. Sie sind für das Funktionieren des
Systems erforderlich, werden jedoch vom Benutzer nicht wahrgenommen und sind für ihn auch nicht direkt von
Bedeutung, z.B. Fehlerbehandlung. Welche Basisfunktionen im Einzelfall nötig sind, hängt teilweise von den
Erwartungen des Auftraggebers ab, etwa von seinen Ansprüchen in Bezug auf Vertraulichkeit von Dateninhalten,
aber auch von den Möglichkeiten und Grenzen der vorgesehenen Betriebsplattform. Oft gibt es Standardlösungen für
Basisfunktionen, die von verschiedenen Anwendungen genutzt werden können, denn sie hängen nur von der
technischen Umsetzung auf der Plattform ab. Zwei Beispiele:
...................................
Datenzugriffsschicht
Betriebswirtschaftlich geprägte Systeme beruhen meist auf einem großen Datenbestand, der in
relationaler Form gespeichert wird. Wird die Fachlogik objektorientiert programmiert, so entsteht
ein Strukturbruch, der durch technische Module überwunden werden kann (objekt-relationale
Zugriffsschicht). Sie sind oft mit Code-Generatoren oder Frameworks realisiert. Die
Konstruktionssicht legt Richtlinien zum Einsatz solcher Werkzeuge fest und beschreibt
exemplarisch die Abbildung eines typischen fachlichen Objekts auf seine Repräsentation in der
Datenbank.
Fehlerbehandlung
Die Konstruktion legt Richtlinien zur Nutzung der entsprechenden Exception-Handling-Konzepte
in der Programmierumgebung fest. Für heterogene Client-Server-Umgebungen beschreibt die
Konstruktion, ob bzw. wie Remote-Exceptions ihren Weg vom Server zum Client finden. Weniger
wichtig ist hingegen, dass jede einzelne denkbare Ausnahmesituation erkannt und beschrieben
wird. Eine vergröberte Betrachtung und die exemplarische Beschreibung typischer
Ausnahmesituationen sind für die Konstruktionssicht ausreichend.
4.3.2 Schichten
Ein probates Mittel der Strukturierung in der Konstruktion besteht darin, Softwareschichten zu bilden. Klassisch sind
drei Schichten: Komponenten und Module für die
1. Steuerung der Schnittstellen zur Außenwelt (Anwender, Sensoren/Aktoren)
2. Anwendungslogik
3. Schnittstellen zum Basissystem (Betriebssystem, Geräte, Kommunikation etc.)
4.3.3 Parallelität
Betriebliche Systeme sind datenintensiv und speichern langlebige Objekte in Datenbanken. Sie haben meist viele
Benutzer. Letzteres zeigt sich jedoch nicht in der Modulstruktur, sondern in der Nutzung von Mechanismen der
Systemplattform, das sind vor allem Transaktionsmonitor, Betriebs- und Datenbanksystem. Letztlich sind es
Betriebssystemprozesse, in denen die Transaktionen der gleichzeitig aktiven Benutzer parallel ausgeführt werden.
Somit kann sich die Konstruktion beschränken auf die modulare Gestaltung der Funktionalität für einen einzelnen
Benutzer und muss nur festlegen, wie deren Ausführung für die vielen Benutzer vom Basissystem zu organisieren
ist.
Sie gibt außerdem vor, wie Konflikte behandelt werden, die dadurch entstehen können, dass mehrere Benutzer
gleichzeitig mit denselben Daten arbeiten. Man muss zwischen zwei grundsätzlich verschiedenen Strategien
entscheiden: Konfliktvermeidung (ex ante) oder Konfliktbewältigung (ex post). Letztere nennt man optimistisch,
weil sie auf der Annahme beruht, dass der Konfliktfall nur selten eintritt und es dann schon gut gehen wird. Die
AT -- Konstruktion
Ex-ante-Strategie heißt pessimistisch, weil sie für hohe Konflikthäufigkeit vorgesehen ist; ihre Realisierung ist
aufwendig. Parallele Programmierung ist erheblich schwieriger und fehleranfälliger als sequenzielle. Deshalb soll
man sie möglichst vermeiden (auch wenn sie viele Programmierer intellektuell reizt). Es ist Sache der Konstruktion,
mit welchen Systemmechanismen die tatsächlich notwendige Parallelverarbeitung realisiert wird.
4.3.4 Mehrere Exemplare eines Moduls
Das Modul als gedankliche Einheit aus Daten und Funktionen repräsentiert ein fachlichen Konzept. Es wird einmalig
in der Konstruktion beschrieben und in der Regel auch nur einmal als Programm implementiert - es sei denn,
technische Umstände erzwingen eine Programmierung des selben Moduls in unterschiedlichen Sprachen, wie dies
z.B. bei Apps heute nötig ist, die auf Apple-Geräten und auf Android verfügbar sein sollen.
Manchmal hat man es innerhalb eines Moduls explizit mit unterschiedlichen Exemplaren eines (anderen) Moduls zu
tun. Beispielsweise wird man sich sich in einer Rechnung auf mehrere RechnungsPositionen beziehen.
Man iteriert etwa über die Positionen, um deren Gesamtwert zu ermitteln. Die Rechnung besteht aus 1..n
Exemplaren der RechnungsPosition - klassische Datenmodelle oder UML-Klassendiagramme beschreiben
solche 1:N-Beziehungen.
Exkurs in die Programmsicht:
In der Datenbank sind die Positionen über irgendeinen (fachlichen oder technischen) Schlüsselbegriff miteinander
verknüpft. Ein Programm hat mehrer Möglichkeiten, den Rechnungsbetrag zu ermitteln:
1. Das Programm kann dafür sorgen, dass die Rechnung sich "ihre" Positionen über ein geeignetes SQL-Statement
holt, um die Werte zu addieren. Dieses "Holen" ist eine technische Transformation von persistenten Daten in
Objekte des Arbeitsspeichers. Sind die Positionen geladen, so ensteht im Arbeitsspeicher ein Ausschnitt des
persistenten Objektgeflechts, bei dem die Objekte über Pointer (Verweise auf Adressen im Arbeitsspeicher)
verbunden sind. Die Rechnung kann irgendein technisches Konstrukt zur Verwaltung von Mengen (Array,
Collection-Klasse) dazu benutzen, die Verweise auf "ihre" Positionen zu verwalten. Ist der Rechnungsbetrag
ermittelt, so stehen die RechnungsPositionen weiterhin zur Verfügung, etwa um Verkaufsstatistiken zu
aktualisieren.
2. Alternativ kann das Programm dafür sorgen, dass die Positionen sequentiell geholt werden, wobei eine Position
jedoch sofort wieder "vergessen wird", wenn ihr Wert zur Rechnungssumme addiert wurde. Die Liste der
Positions-Exemplare existiert dann nicht innerhalb des Arbeitsspeichers. Jedes Exemplar existiert nur während
der Addition im Arbeitsspeicher.
3. Das Programm kann den Prozess der Addition komplett an die Datenbank delegieren, zumindest, wenn es sich
um eine relativ einfache mathematische Operation handelt. Selbst wenn die Operationen komplizierter werden,
könnte eine Implementierung die entsprechenden Algorithmen als "Triggerfunktionen" für die Datenbank
bereitstellen, so dass sie beim Iterieren über die RechnungsPositionen unter der Kontrolle der Datenbank
ausgeführt werden. Die Verknüpfung der Rechnung zu ihrer Position ist dann quasi "automatisch" da. Wie lange
sie lebt, hängt vom Entwurf des SQL-Statements ab.
Was bedeutet das für die Konstruktion?
Einerseits muss die Konstruktion grundlegende Vorgaben für die technische Umsetzung machen. Beispielsweise
muss sie festlegen, ob die Variante (3) erlaubt sein soll, oder nicht. Denn dieser Weg geht in der Regel mit
Abhängigkeiten vom Hersteller der Datenbank einher.
Auf der anderen Seite sollte die Konstruktion den Summationsvorgang möglichst allgemein gültig beschreiben. Es
genügt, wenn sie in der Vorstellung lebt, dass Rechnungen mit ihren Rechnungspositionen verknüpft sind. Das
Modul Rechnung kennt die ihm zugeordneten Exemplare der RechnungsPosition und kann daher deren
Schnittstelle benutzen. Es kann über 'seine' Positionen iterieren und muss dazu nicht jedesmal einen gedanklichen
Schritt der Art "hole alle meine Positionen" vorwegschalten. Ob Variante (1) oder (2) bei der technischen
Umsetzung zweckmäßiger sind, kann nach unserem Verständnis der Programm-Sicht überlassen werden.
7
AT -- Konstruktion
4.3.5 Bezeichner und Sprache
Wenn die Konstruktion an bestimmten Stellen Bezeichner (Namen) für Module, Attribute oder Funktionen
verwendet, stellt sich die Frage nach deren Übertragbarkeit in die Programmsicht. Ein Merkmal wie "nächste freie
ISBN" ist wegen des Umlauts nur in wenigen Programmiersprachen syntaktisch zulässig. Es ist das erklärte Ziel der
Konstruktion, als Basis für unterschiedliche Implementierungen brauchbar zu sein. Begriffliche Konsistenz zwischen
Konstruktion und Programm ("Traceability") ist generell wünschenswert. Die Konstruktionssicht tut daher gut daran,
Namen so zu wählen, dass sie 1:1 oder durch eine bijektive Abbildung in unterschiedliche Programmsichten
überführbar sind. Umlaute taugen dazu nicht, da der Rückweg nicht eindeutig wäre (aus "ue" kann man nicht überall
"ü" machen, sonst würde aus einem "Feuer" eine "Feür" werden). Transformationen von CamelCase, Binde- und
Unterstrichen sind allerdings meist akzeptabel bzw. unvermeidlich. Leerzeichen in Namen verursachen fast immer
Probleme. Das Weglassen von Leerzeichen hat zudem den Vorteil, dass zusammengesetzte Begriffe wie etwa
naechsteFreieISBN sofort als 'präzise gemeinte Begriffe' auch ohne weitere textuelle Auszeichnung erkennbar sind.
Die Frage nach der Sprache stellt sich noch viel grundsätzlicher: Die Sprache des Anwenders (z.B. Deutsch) ist im
Zeitalter globaler Arbeitsteilung nicht automatisch die Arbeits- und Denksprache der Software-Architekten und
Entwickler. Und diese wiederum ist nicht automatisch die vorgesehene Sprache für die Implementierung (Quellcode,
Kommentare). Unser Verständnis für die Bedeutung der Konstruktionssicht lässt nicht zu, dass man
Konstruktionsdokumente als privates Skizzenmaterial der Software-Architekten und Entwickler ansieht. Deren
Muttersprache scheidet also aus. Die fachliche Sicht ist mit großer Wahrscheinlichkeit in der nationalen
Muttersprache des Benutzers / Auftraggebers dokumentiert; lediglich bei internationalen Konzernen werden solche
Dokumente von vornherein in Englisch erstellt. Sehr oft wird eine Implementierung in Englisch angestrebt, um bei
der Wartung auf Mitarbeiter unterschiedlicher Herkunft zurückgreifen zu können. Ist ein sprachlicher Bruch also
unvermeidlich, so stellt sich die Frage "vor oder nach der Konstruktion?".
Wir plädieren dafür, die Konstruktion in der selben Sprache wie die Implementierung zu verfassen. Eine besonders
wichtige Aufgabe der Konstruktion ist in solchen Fällen der Aufbau eines zweisprachigen Glossars, in dem alle
nationalen fachlichen Begriffe der anglisierten Form zugeordnet werden. Ein derartiges Glossar ist an der
Übergangsstelle zwischen Anwendung und Konstruktion angesiedelt. Man beobachtet häufig, dass im Laufe der Zeit
die Autoren der fachlichen Sicht die Zuständigkeit für die Aktualisierung eines solchen Glossars übernehmen.
Quellenangaben:
8
Quelle(n) und Bearbeiter des/der Artikel(s)
Quelle(n) und Bearbeiter des/der Artikel(s)
AT -- Konstruktion Quelle: http://software-architecture.org/wiki/index.php?oldid=8163 Bearbeiter: Gero Scholz
Quelle(n), Lizenz(en) und Autor(en) des Bildes
File:Konzepte und Begriffe der Perspektive Konstruktion.png Quelle: http://software-architecture.org/wiki/index.php?title=Datei:Konzepte_und_Begriffe_der_Perspektive_Konstruktion.png
Lizenz: unbekannt Bearbeiter: Gero Scholz
9