iSAQB® Glossar für Begriffe rund um Softwarearchitektur

Siehe Kopplung.

(Abstrakte) Elemente höherer Ebenen sollten nicht von (spezifischen) Elementen niedrigerer Ebenen abhängen. Details sollten von Abstraktionen abhängen ([Martin-2003]). Eines der SOLID-Prinzipien, das Brett Schuchert anschaulich erläutert, und das eng mit dem SDP und SAP zusammenhängt.

Statt dass Ihre Objekte oder eine Fabrik eine Abhängigkeit erzeugen, übergeben Sie die benötigten Abhängigkeiten an den Konstruktor oder über Eigenschaft-Setter. Damit machen Sie die Erzeugung von spezifischen Abhängigkeiten zum Problem anderer Leute.

In der Architekturdokumentation: Ort, an dem Artefakte gespeichert werden, ehe sie durch einen automatischen Prozess zu einem konsistenten Dokument zusammengestellt werden.

Im Domain-driven Design: Die Ablage ist ein Baustein des Domain-Driven Designs. Eine Ablage verbirgt technische Details der Infrastrukturschicht vor der Domänenschicht. Ablagen geben Entitäten zurück, die in der Datenbank bestehen.

Kennzahl für den Quellcode von objektorientierten Systemen: Zahl der abstrakten Typen (Schnittstellen und abstrakte Klassen), geteilt durch die Gesamtzahl der Typen.

Betrachtung eines Elements, die sich auf die für einen bestimmten Zweck maßgeblichen Informationen konzentriert und die übrigen Informationen ignoriert.

(Syn.: Kompromiss). Erreichte oder ausgehandelte Balance zwischen zwei gewünschten oder vorgegebenen, aber üblicherweise unvereinbaren oder widersprüchlichen Eigenschaften. Beispielsweise muss in der Softwareentwicklung in der Regel ein Kompromiss zwischen Speicherbedarf und Laufzeitgeschwindigkeit gefunden werden.

Umgangssprachlicher gesagt, wenn etwas zunimmt, muss etwas anderes abnehmen.

Und noch umgangssprachlicher: Es gibt nichts umsonst. Für jedes Qualitätsmerkmal ist bei anderen Qualitätsmerkmalen ein Preis zu zahlen.

Zugriffskontrolllisten (Access Control Lists, ACL) repräsentieren die Autorisierung eines Principals, um auf eine spezifische Entität zuzugreifen. Eine ACL, die einer Entität zugeordnet ist, ist eine Liste von Principals zusammen mit ihren Berechtigungen. Viele Dateisysteme - darunter Windows und POSIX - unterstützen die Verwendung von ACLs zur Zugriffskontrolle.

Da ACL sich nicht gut im großen Maßstab skalieren lassen, ist eine rollenbasierte Modellierung der Zugriffskontrolle (RBAC) gängig.

Ein Adapter ist ein Entwurfsmuster, das die Nutzung einer vorhandenen Schnittstelle von einer anderen Schnittstelle aus ermöglicht. Er wird häufig dazu verwendet, vorhandene Komponenten ohne Veränderung ihres Quellcodes dazu zu bringen, mit anderen Komponenten zusammenzuarbeiten.

Ein Aggregat ist ein Baustein des Domain-Driven Designs. Aggregate sind komplexe Objektstrukturen, die aus Entitäten und Wertobjekten bestehen. Jedes Aggregat hat eine Root-Entität und wird in Bezug auf Änderungen als Einheit betrachtet. Aggregate stellen die Konsistenz und Integrität ihrer enthaltenen Entitäten mit Invarianten sicher.

Eine Form der Komposition in der objektorientierten Programmierung. Sie unterscheidet sich von der Komposition dadurch, dass sie keinen Besitz impliziert. Wenn das Element vernichtet wird, bleiben die enthaltenen Elemente intakt.

Schulungsanbieter mit gültiger Akkreditierung des iSAQB®.

Prüfungsverfahren und Zertifizierung durch eine ermächtigte Akkreditierungsstelle (in diesem Fall das iSAQB®) zur Bestätigung, dass der Antragsteller die organisatorischen, technischen und qualitativen Anforderungen für Schulungsanbieter erfüllt.

Der Antrag auf Akkreditierung ist über die vom iSAQB benannte Akkreditierungsstelle einzureichen. Die Akkreditierungsstelle ist Ansprechpartner für alle Fragen des Schulungsanbieters während der Akkreditierung. Sie koordiniert das Akkreditierungsverfahren, führt die offizielle Bewertung der eingereichten Unterlagen durch und organisiert die technische Beurteilung in der AUDIT-ARBEITSGRUPPE.

Ein Konzept von Domain-driven Design: Eine allgegenwärtige Sprache ist eine Sprache, die um das Domänenmodell strukturiert ist. Sie wird von allen Teammitgliedern zur Verbindung aller Aktivitäten des Teams mit der Software genutzt. Die allgegenwärtige Sprache ist lebendig, entwickelt sich während eines Projekts weiter und verändert sich während des gesamten Lebenszyklus der Software.

Eignung für einen bestimmten Zweck.

Formale Möglichkeit zur Beschreibung verschiedener Ansätze eines Angreifers zur Erreichung bestimmter Ziele. Üblicherweise ist der Baum so aufgebaut, dass sich das Angriffsziel oben befindet und die verschiedenen Ansätze als Kindknoten dargestellt sind. Wahrscheinlich hat jeder Ansatz Abhängigkeiten, die wiederum als Kindknoten aufgeführt sind. Die Möglichkeit einer bestimmten Angriffsweise auf ein IT-System kann durch Zuweisung von zusätzlichen Attributen zu jedem Knoten analysiert werden. Mögliche Beispiele sind die geschätzten Kosten eines Angriffs oder die Frage der Möglichkeit eines Angriffsansatzes mittels Einbeziehung von Gegenmaßnahmen.

Siehe Bruce Schneier zu "Modeling security threats".

Kostenfreies Open-Source Template zur Kommunikation und Dokumentation von Softwarearchitekturen. arc42 besteht aus 12 (optionalen) Teilen oder Abschnitten.

TODO

Siehe Softwarearchitektur.

Konventionen, Grundsätze und Praktiken für die Beschreibung von Architekturen, die in einem spezifischen Anwendungsbereich und/oder einer Gemeinschaft von Stakeholdern festgelegt wurden (gemäß Definition in ISO/IEC/IEEE 42010).

Beispiele:

Siehe Architekturziel.

Die Architekturbegründung enthält Erläuterungen, Rechtfertigungen oder Argumentationen zu getroffenen Architekturentscheidungen. Die Begründung einer Entscheidung kann die Entscheidungsgrundlage, berücksichtige Alternativen und Kompromisse, mögliche Folgen der Entscheidung und Quellenangaben für zusätzliche Informationen enthalten (gemäß Definition in ISO/IEC/IEEE 42010).

Arbeitsergebnis, das genutzt wird, um eine Architektur zum Ausdruck zu bringen (gemäß Definition in ISO/IEC/IEEE 42010).

Ein Architekturbeschreibungselement ist ein beliebiges Konstrukt in einer Architekturbeschreibung. Architekturbeschreibungselemente sind die grundlegendsten Konstrukte, die in ISO/IEC/IEEE 42010 behandelt werden. Bei allen in ISO/IEC/IEEE 42010 definierten Begriffen handelt es sich um eine Spezialisierung des Konzepts eines Architekturbeschreibungselements (gemäß Definition in ISO/IEC/IEEE 42010).

Architekturbeschreibungssprachen (ADL) sind jegliche Ausdrucksformen zur Verwendung in Architekturbeschreibungen (gemäß Definition in ISO/IEC/IEEE 42010).

Beispiele sind Rapide, Wright, SysML, ArchiMate und die Sprachen der verschiedenen Blickwinkel in RM-ODP [ISO 10746].

Quantitative oder qualitative Beurteilung einer (Software- oder System-) Architektur. Erlaubt es, festzustellen, ob eine Architektur ihre Zieleigenschaften oder Qualitätsmerkmale erreichen kann.

Siehe Beurteilung

Arbeitsergebnis zur Festlegung der Konventionen für den Aufbau, die Interpretation und die Nutzung von Architektursichten für spezifische Systembelange (gemäß Definition in ISO/IEC/IEEE 42010).

Entscheidung mit nachhaltiger oder wesentlicher Auswirkung auf die Architektur.

Beispiel: Entscheidung über Datenbanktechnologie oder technische Grundlagen der Benutzeroberfläche.

Gemäß ISO/IEC/IEEE 42010 bezieht sich eine Architekturentscheidung auf Systembelange. Jedoch gibt es häufig kein einfaches Mapping zwischen den beiden. Eine Entscheidung kann sich auf verschiedene Weise auf die Architektur auswirken. Dies kann in der Architekturbeschreibung dargestellt werden (gemäß Definition in ISO/IEC/IEEE 42010).

Eine Architektursicht besteht aus einem oder mehreren Architekturmodellen. Ein Architekturmodell verwendet für die betreffenden Belange geeignete Modellierungskonventionen. Diese Konventionen sind in der Modellart für dieses Modell festgelegt. In einer Architekturbeschreibung kann ein Architekturmodell Teil von mehr als einer Architektursicht sein (gemäß Definition in ISO/IEC/IEEE 42010).

Ein Architekturmuster beschreibt eines grundlegendes strukturelles Organisationsschema für Softwaresysteme. Es liefert eine Reihe von vordefinierten Teilsystemen, spezifiziert ihre Verantwortlichkeiten und enthält Richtlinien für die Organisation der Beziehungen zwischen ihnen ([Buschmann+1996], Seite 12). Vergleichbar mit Architekturstil.

Beispiele:

Eine Darstellung eines Systems aus einer spezifischen Perspektive. Wichtige und bekannte Sichten:

[Bass et al. 2022] und [Rozanski & Woods 2011] erörtern dieses Konzept ausführlich.

Laut ISO/IEC/IEEE 42010 ist eine Architektursicht ein Arbeitsergebnis, das die Architektur eines Systems aus der Perspektive spezifischer Systembelange darstellt (gemäß Definition in ISO/IEC/IEEE 42010).

Beschreibung von Element- und Beziehungstypen zusammen mit Einschränkungen ihrer Nutzungsweise. Häufig Architekturmuster genannt. Beispiele: Pipes und Filter, Model-View-Controller, Schichten.

TODO

(Syn.: Architektur-Qualitätsziel, Architektur-Qualitätsanforderung): Ein Qualitätsmerkmal, das ein System erreichen muss und bei dem es sich um eine Architekturfrage handelt.

Daher ist die Architektur so zu entwerfen, dass das Architekturziel erfüllt wird. Diese Ziele sind im Gegensatz zu (kurzfristigen) Projektzielen häufig langfristig.

Greifbares Nebenprodukt, das während der Softwareentwicklung erstellt oder erzeugt wird. Beispiele für Artefakte sind Anwendungsfälle, alle Arten von Diagrammen, UML-Modelle, Anforderungs- und Entwurfsunterlagen, Quellcode, Testfälle, Klassendateien, Archive.

"In der Informationssicherheit, Computersicherheit und Netzwerksicherheit sind Assets jegliche Daten, Geräte oder sonstigen Komponenten der Umgebung, die Aktivitäten in Zusammenhang mit Informationen unterstützen. Assets umfassen im Allgemeinen Hardware (z.B. Server und Switches), Software (z.B. missionskritische Anwendungen und Supportsysteme) und vertrauliche Informationen."

(Übersetztes englisches Zitat aus Wikipedia)

Definiert eine Beziehung zwischen Objekten (im Allgemeinen zwischen Modulen). Jede Assoziation lässt sich durch Kardinalitäten und (Rollen-)Namen im Detail beschreiben.

Siehe Kopplung, Abhängigkeit und Beziehung

Algorithmen der asymmetrischen Kryptografie sind so ausgelegt, dass zur Verschlüsselung und zur Entschlüsselung unterschiedliche Schlüssel verwendet werden. Der Schlüssel für die Verschlüsselung wird "öffentlicher Schlüssel" genannt und der Schlüssel für die Entschlüsselung "privater Schlüssel". Der öffentliche Schlüssel kann veröffentlicht werden und von jedem zur Verschlüsselung von Informationen verwendet werden; diese können nur von der Partei, die im Besitz des privaten Schlüssels für die Entschlüsselung ist, gelesen werden. Siehe [Schneier, Bruce].

Asymmetrische Kryptografie ist die Grundlage für PKI und digitale Signaturen.

Architecture Tradeoff Analysis Method. Qualitative Architekturbewertungsmethode, basierend auf einem (hierarchischen) Qualitätsbaum und konkreten Qualitätsszenarien. Grundidee: Vergleich feinkörniger Qualitätsszenarien ("Qualitätsanforderungen") mit den entsprechenden Architekturansätzen zur Identifizierung von Risiken und Kompromissen.

Die Audit-Arbeitsgruppe ist für die technische Beurteilung der Schulungsunterlagen sowie für die Überwachung und Beurteilung der Schulungen zuständig. Die vom iSAQB® ermächtigten Mitglieder der Audit-Arbeitsgruppe sind von den Schulungsanbietern unabhängig. Der Schulungsanbieter wird von der Akkreditierungsstelle über das Ergebnis der Beurteilungen (die jeweilige Akkreditierungsempfehlung der Audit-Arbeitsgruppe) informiert.

Authentifizierung ist der Vorgang der Bestätigung der Identitätsbehauptung einer gegebenen Entität. Dies geschieht üblicherweise durch Überprüfung von mindestens einem der dem System bekannten Authentifizierungsfaktoren:

Für eine stärkere Authentifizierung können mehrere Faktoren oder mindestens Faktoren aus zwei Kategorien verlangt werden.

"Autorisierung ist der Vorgang der Spezifizierung von Zugriffsrechten für Ressourcen in Zusammenhang mit Informationssicherheit und Computersicherheit im Allgemeinen und mit Zugriffskontrolle im Besonderen. Förmlicher bezeichnet "autorisieren" die Festlegung einer Zugrissrichtlinie."

(Übersetztes englisches Zitat aus Wikipedia)

Ein Grundsatz für die Gestaltung der Struktur von Softwaresystemen (siehe auch Packaging-Prinzipien). Er besagt, dass der Abhängigkeitsgraph eines Systems keine Zyklen enthalten darf, was auch eine Notwendigkeit für die hierarchische Zerlegung ist.

Die Vermeidung von Abhängigkeitszyklen ist für lose Kopplung und Wartbarkeit entscheidend, da alle Komponenten in einem Abhängigkeitszyklus effektiv, auch wenn mittelbar, voneinander abhängen, wodurch es schwierig ist, einen Teil des Zyklus isoliert zu verstehen, zu ändern oder zu ersetzen (siehe auch [Lilienthal-2019]).

Auch wenn Robert C. Martin ([Martin-2003]) sich auf große Komponenten objektorientierter Software bezog, ist ADP ein universeller Grundsatz. Er geht (mindestens) auf einen der Ursprünge der Softwarearchitektur zurück, den Klassiker von 1972 "On the Criteria To Be Used in Decomposing Systems into Modules" ([Parnas-1972]), der zu dem Ergebnis gelangt, dass eine hierarchische Struktur zusammen mit einer "sauberen" Zerlegung wünschenswerte Eigenschaften eines jeden Systems sind.

Es kann argumentiert werden, dass ein Abhängigkeitszyklus, selbst vor Berücksichtigung seiner verschiedenen praktischen Probleme, logisch bereits so fehlerhaft ist wie ein Zirkelargument oder eine Zirkeldefinition. Als struktureller Widerspruch kann ein Zyklus weder ein angemessenes noch ein aussagekräftiges Modell der inhärenten Natur und des Zwecks eines Systems sein. Alleine diese konzeptuelle Abweichung führt geradezu mit Sicherheit zur Entstehung von Problemen. Und genau das soll durch einen Prinzip-Ansatz verhindert werden.

Allgemeiner oder abstrakter Begriff für alle Arten von Artefakten, aus denen Software aufgebaut ist. Teil der statischen Struktur (Bausteinsicht) von Softwarearchitektur.

Bausteine können hierarchisch strukturiert sein, sie können andere (kleinere) Bausteine enthalten.

Einige Beispiele für alternative (konkrete) Bezeichnungen von Bausteinen:
Komponente, Modul, Paket, Namensraum, Klasse, Datei, Programm, Teilsystem, Funktion, Konfiguration, Datendefinition.

Zeigt die statische Struktur des Systems, die Organisationsweise des Quellcodes. Üblicherweise hierarchisch, ausgehend von der [Kontextabgrenzung]. Ergänzt durch ein oder mehrere [Laufzeitsichten].

Erläuterung der Argumentation oder Argumente, die einer Architekturentscheidung zugrunde liegen.

Belange in Bezug auf eine Architektur sind Anforderungen, Ziele, Einschränkungen, Absichten oder Bestrebungen eines Stakeholders für diese Architektur. ([Rozanski & Woods 2011], Kapitel 8)

Gemäß ISO/IEC/IEEE 42010 ist Belang definiert als (System-)Interesse an einem System, das für einen oder mehrere Stakeholder relevant ist (gemäß Definition in ISO/IEC/IEEE 42010).

Belange beziehen sich auf jegliche Einflüsse auf ein System in seiner Umgebung, wie Entwicklungs-, Geschäfts- und Betriebseinflüsse sowie technologische, organisatorische, politische, wirtschaftliche, rechtlichen, regulatorische, ökologische und soziale Einflüsse.

(Entwurfsmuster) "…​ in dem ein Objekt eine Liste seiner abhängigen Strukturen, Observer genannt, führt und sie automatisch, in der Regel durch Aufruf einer ihrer Methoden, über Zustandsänderungen benachrichtigt." (Übersetztes englisches Zitat aus Wikipedia)

Das Beobachtermuster ist ein wesentlicher Bestandteil des MVC-Architekturmusters.

Betrachtetes System (oder einfach System) bezieht sich auf das System, dessen Architektur bei der Erstellung der Architekturbeschreibung betrachtet wird (gemäß Definition in ISO/IEC/IEEE 42010).

Siehe auch Bewertung.

Zusammenstellung von Informationen über Status, Risiken oder Schwächen eines Systems. Die Beurteilung kann potenziell alle Aspekte (Entwicklung, Organisation, Architektur, Code usw.) betreffen.

Allgemeiner Begriff zur Bezeichnung einer Art von Abhängigkeit zwischen Elementen einer Architektur. In Architekturen werden unterschiedliche Arten von Beziehungen verwendet, z.B. Aufruf, Benachrichtigung, Besitz, Containment, Erzeugung oder Vererbung.

Sicht auf einen Baustein (oder eine Komponente), die die interne Struktur verbirgt. Blackboxen achten das Geheimnisprinzip. Sie müssen klar definierte Ein- und Ausgabeschnittstellen sowie eine präzise formulierte Verantwortlichkeit oder ein präzise formuliertes Ziel haben. Optional definiert eine Blackbox einige Qualitätsmerkmale, wie beispielsweise zeitliches Verhalten, Durchsatz oder Sicherheitsaspekte.

Arbeitsrichtung (oder Bearbeitungsstrategie) für Modellierung und Entwurf. Ausgehend von detaillierten oder konkreten Aspekten wird auf etwas Allgemeineres oder Abstrakteres hingearbeitet.

"Beim Bottom-up-Ansatz werden zunächst die einzelnen Grundelemente des Systems mit hohem Detailgrad spezifiziert. Diese Elemente werden dann miteinander zu größeren Teilsystemen verknüpft." (Übersetztes englisches Zitat aus Wikipedia)

Ein Architekturmuster zur Strukturierung von verteilten Softwaresystemen mit entkoppelten Komponenten, die über (üblicherweise Remote-) Serviceaufrufe interagieren.

Broker sind für die Koordinierung der Kommunikation, wie die Weiterleitung von Anfragen, sowie die Übermittlung von Ergebnissen und Ausnahmen zuständig.

Entwurfsmuster, bei dem eine Abstraktion von ihrer Implementierung entkoppelt ist, sodass beide unabhängig voneinander variieren können. Wenn Ihnen das (wie den meisten Menschen) unverständlich erscheint – sehen Sie hier nach.

Das C4 Model for Software Architecture Documentation wurde von Simon Brown entwickelt. Es besteht aus einer hierarchischen verknüpften Menge an Softwarearchitekturdiagrammen für Kontext, Container, Komponenten und Code.

Die Hierarchie der C4 Diagramme stellt verschiedene Abstraktionslevel bereit, wobei jedes ist für andere Leser relevant ist.

Ein Zertifizierungsstelle (Certificate Authority, CA) stellt digitale Zertifikate für ein gegebenes Subjekt in einer PKI aus. Üblicherweise besteht Vertrauen in diese Stelle, das zum gleichen Maß an Vertrauen in die ausgestellten Zertifikate führt.

Ein Beispiel ist die weitverbreitete TLS-PKI, bei der jeder Browser die Wurzelzertifikate einer festgelegten Liste von CA enthält. Diese CA überprüfen dann die Identität eines gegebenen Internet-Domaininhabers und signieren sein Zertifikat digital für die Verwendung mit TLS.

Siehe Schutzziele

"Cloudcomputing ist ein Modell zur Ermöglichung eines allgegenwärtigen, bequemen, auf Abruf verfügbaren Netzzugriffs auf einen gemeinsamen Pool konfigurierbarer Rechenressourcen (z.B. Netzwerke, Server, Speicher, Anwendungen und Dienste), der schnell bereitgestellt und mit geringfügigem Verwaltungsaufwand bzw. minimalen Eingriffen durch den Dienstanbieter freigegeben werden kann."

Übersetztes englisches Zitat von NIST (National Institute of Standards and Technology).

Die NIST-Definition enthält die folgenden fünf Eigenschaften (die ebenfalls von der oben genannten NIST-Quelle stammen, jedoch verkürzt wurden):

Ein Grundsatz für die Gestaltung der Struktur von Softwaresystemen (siehe auch Packaging-Prinzipien). Er ist eine direkte und ausdrückliche Neuformulierung des Single-Responsibility-Prinzips für größere Komponenten.

Die Unterkomponenten einer Komponente sollen idealerweise genau dieselben Änderungsgründe haben. Ein Änderungsantrag, der sich auf eine von ihnen auswirkt, soll sich auf sie alle, aber auf nichts außerhalb ihrer enthaltenden Komponente auswirken.

Dadurch würde sich jeder erwartete Änderungsantrag auf eine minimale Zahl an Komponenten auswirken. Oder anders gesagt: Jede Komponente wäre gegenüber einer maximalen Zahl an erwarteten Änderungsanträgen geschlossen. Der Begriff erwartet hat an dieser Stelle einige bedeutende Auswirkungen:

Dieses Prinzip führt zu Komponenten mit starker Kohäsion. Es geht auch mit lose gekoppelten Komponenten einher, da verbundene Konzepte, die sich zusammen ändern, in dieselbe Komponente gebündelt werden. Wenn jedes einzelne Konzept von einer einzigen Komponente ausgedrückt wird, gibt es keine unnötigen Kopplungen zwischen Komponenten.

Ein Grundsatz für die Gestaltung der Struktur von Softwaresystemen (siehe auch Packaging-Prinzipien). Die Unterkomponenten (Klassen) einer Komponente sollen genau die sein, die zusammen (wieder)verwendet werden. Oder andersherum: Komponenten, die zusammen (wieder)verwendet werden, sollen in eine größere Komponente gepackt werden. Dies bedeutet auch, dass Unterkomponenten, die nicht häufig zusammen mit anderen Unterkomponenten verwendet werden, nicht in der entsprechenden Komponente sein sollen.

Diese Perspektive hilft bei der Entscheidung, was in eine Komponente gehört und was nicht. Sie zielt auf eine Systemzerlegung mit lose gekoppelten und stark kohärenten Komponenten ab.

Dies steht natürlich im engen Zusammenhang mit dem Single-Responsibility-Prinzip. Außerdem besteht ein Zusammenhang zum Schnittstellenaufteilungsprinzip, da das Prinzip sicherstellt, dass Clients nicht gezwungen werden, von Konzepten abzuhängen, die für sie bedeutungslos sind.

Certified Professional for Software Architecture® — die gängige Bezeichnung für die verschiedenen Zertifizierungsstufen des iSAQB. Die bekanntesten Zertifizierungen sind das Foundation Level (CPSA-F) und das Advanced Level (CPSA-A).

(Command-Query-Responsibility-Segregation): Trennt die Elemente, die Daten manipulieren (Befehl) von denen, die Daten nur lesen (Abfrage). Diese Trennung ermöglicht verschiedene Optimierungsstrategien für das Lesen und Schreiben von Daten (beispielsweise ist es wesentlich leichter, schreibgeschützte Daten zu cachen, als Daten, die auch abgeändert werden können).

Es gibt ein interessantes eBook von Mark Nijhof zu diesem Thema.

Ein Dienst oder Service beschreibt eine technische, autarke Einheit, die zusammenhängende Funktionalitäten, typischerweise zu einem Themenkomplex, bündelt und über eine klar definierte Schnittstelle zur Nutzung durch andere Bausteine zur Verfügung stellt.

Idealerweise abstrahiert ein Dienst die interne, technische Funktion soweit, dass es für die Nutzung des Dienstes nicht notwendig ist, interne Implementierungsdetails zu kennen oder gar zu verstehen.

Typische Beispiele für extern erreichbare Dienste sind Webservices, Netzwerkdienste, Systemdienste oder auch Telekommunikationsdienste.

(basierend auf Wikipedia)

Ein (üblicherweise schriftliches) Artefakt zur Informationsvermittlung.

Systematisch geordnete Sammlung von Dokumenten und sonstigen Materialien aller Art, die die Nutzung oder Beurteilung erleichtern. Beispiele für "sonstige Materialien": Präsentationen, Videos, Audios, Webseiten, Bilder usw.

Automatischer Prozess, mit dem Artefakte zu einer konsistenten Dokumentation zusammengestellt werden.

"Domain-Driven Design (DDD) ist ein Ansatz zur Softwareentwicklung für komplexe Anforderungen durch tiefreichende Verbindung der Implementierung mit einem sich evolvierenden Modell der Kerngeschäftskonzepte." (Übersetztes englisches Zitat von DDDCommunity). Siehe [Evans-2004].

Siehe auch:

Das Domänenmodell ist ein Konzept von Domain-Driven Design. Das Domänenmodell ist ein System aus Abstraktionen zur Beschreibung ausgewählter Aspekte einer Fachdomäne und kann zur Lösung von Problemen in Zusammenhang mit dieser Domäne verwendet werden.

In ein größeres mechanisches oder elektrisches System eingebettetes System. Eingebettete Systeme haben häufig Echtzeit-Recheneinschränkungen. Typische Eigenschaften von eingebetteten Systemen sind niedriger Stromverbrauch, begrenzter Speicher und begrenzte Verarbeitungsressourcen sowie geringe Größe.

Eine Einschränkung des Freiheitsgrads bei der Erstellung, dem Entwurf, der Implementierung oder der sonstigen Bereitstellung einer Lösung. Einschränkungen sind häufig globale Anforderungen, wie begrenzte Entwicklungsressourcen oder eine Entscheidung der Geschäftsleitung, die einschränkt, wie ein System geplant, entworfen, entwickelt oder betrieben wird.

Gestützt auf eine Definition von Scott Ambler

Eine Entität ist ein Baustein des Domain-Driven Designs. Eine Entität ist ein Kernobjekt einer Geschäftsdomäne mit einer unveränderlichen Identität und einem klar definierten Lebenszyklus. Entitäten mappen ihren Zustand auf Wertobjekte und sind fast immer persistent.

In der Informationstheorie definiert als "Menge an Informationen" in einer Nachricht oder "Unvorhersehbarkeit des Informationsgehalts". Die Entropie eines Kryptosystems wird anhand der Größe des Schlüsselraums gemessen. Größere Schlüsselräume haben eine höhere Entropie und sind, wenn sie nicht durch den Algorithmus selbst fehlerhaft sind, schwerer zu knacken als kleinere. Für sichere kryptografische Vorgänge sind nicht nur zufällige Werte als Input vorgeschrieben, sondern sie sollten auch eine hohe Entropie aufweisen. Die Schaffung von hoher Entropie in einem Computersystem ist nicht trivial und kann die Systemleistung beeinträchtigen.

Siehe [Schneier, Bruce] und Whitewood Inc. zu "Understanding and Managing Entropy" oder SANS "Randomness and Entropy - An Introduction".

Eine explizite Dokumentation der Gründe für Entscheidungen, die beim Entwurf eines Architekturelements getroffen wurden.

Allgemeine oder generische wiederverwendbare Lösung für ein gängiges Problem in einem gegebenen Kontext beim Entwurf. Das ursprünglich von dem berühmten Architekten Christopher Alexander erdachte Konzept von Entwurfsmustern wurde von Softwareentwicklern übernommen.

Unserer Ansicht nach sollte jeder ernsthafte Softwareentwickler zumindest einige Muster aus dem bahnbrechenden Buch Gang-of-Four von Erich Gamma ([GoF: Design-Patterns]) und seinen drei Verbündeten kennen.

Eine Reihe von Richtlinien, die Softwareentwicklern hilft, bessere Lösungen zu entwerfen und zu implementieren, wobei "besser" bedeutet, die folgenden schlechten Eigenschaften zu vermeiden:

Gleichzeitig sollten folgende gute Eigenschaften angestrebt werden:

Diese Eigenschaften wurden von Robert Martin formuliert und stammen von OODesign.com

(Entwurfsmuster) In der klassenbasierten oder objektorientierten Programmierung ist das Entwurfsmuster Fabrikmethode ein Erzeugungsmuster, das Fabrikmethoden oder Fabrikkomponenten zur Erzeugung von Objekten nutzt, ohne die exakte Klasse des zu erzeugenden Objekts spezifizieren zu müssen.

Im Domain-Driven Design: Eine Fabrik kapselt die Erzeugung von Aggregaten, Entitäten und Wertobjekten. Fabriken arbeiten ausschließlich in der Domäne und haben keinen Zugriff auf technische Bausteine (z.B. eine Datenbank).

Zeigt das vollständige System als eine Blackbox innerhalb seiner Umgebung aus fachlicher Perspektive und enthält eine Spezifikation aller Kommunikationspartner (Benutzer, IT-Systeme, usw.) mit Erläuterungen zu den domänenspezifischen Ein- und Ausgaben oder Schnittstellen. Zu beachten ist, dass die spezifischen technischen Lösungen für die Interaktion mit externen Akteuren in der Regel nicht im fachlichen Kontext dargestellt werden sollten, da sie zum technischen Kontext) gehören.

Siehe Kontextabgrenzung.

Strukturentwurfsmuster. Eine Fassade bietet eine einfache Schnittstelle zu einem komplexen oder komplizierten Baustein (dem Provider) ohne Modifikationen am Provider.

Teil des "Pipes und Filter"-Architekturstils, der Daten erzeugt oder transformiert. Filter werden üblicherweise unabhängig von anderen Filtern ausgeführt.

"Eine architektonische Fitnessfunktion bietet eine objektive Integritätsbewertung einiger architektonischer Merkmale." ([Ford+2017]).

Eine Fitnessfunktion wird aus manuellen Bewertungen und automatisierten Tests abgeleitet und zeigt, inwieweit die Architektur- oder Qualitätsanforderungen erfüllt werden.

Fundamental Modeling Concepts (FMC)

Grafische Notation für die Modellierung und Dokumentation von Softwaresystemen. Von ihrer Website:
"FMC bietet einen Rahmen für die umfassende Beschreibung von softwareintensiven Systemen. Es basiert auf einer präzisen Terminologie und wird durch eine leicht verständliche grafische Notation unterstützt."

(Synonym: Typ- oder Methodensignatur) definiert die Eingabe und Ausgabe von Funktionen oder Methoden.

Eine Signatur kann enthalten:

Ein (Entwurfs- oder Architektur-)Muster: Elemente, die den Zugriff auf (üblicherweise externe) Systeme oder Ressourcen kapseln. Siehe auch Wrapper, Adapter.

Ein Plan des Unternehmens, der eine gemeinsame Verständnisgrundlage der Organisation bildet und zur Abstimmung von strategischen Zielen und taktischen Anforderungen genutzt wird.

Systematischer Ansatz zur Erreichung der gewünschten Qualitätsmerkmale. Entwickelt und dokumentiert von Christine Hofmeister (Siemens Corporate Research). Die globale Analyse wird in [Hofmeister+2000] beschrieben.

Siehe hybrider Architekturstil.

Informelle Regel, Faustformel. Möglichkeit zur Problemlösung, die nicht mit Sicherheit optimal, aber in gewisser Weise ausreichend ist. Beispiele aus dem objektorientierten Entwurf oder Benutzeroberflächenentwurf.

Kombination aus zwei oder mehreren existierenden Architekturstilen oder -mustern. Beispielsweise ein in eine Schichtstruktur eingebettetes MVC-Konstrukt.

Norm Recommended Practice for Architectural Description of Software-Intensive Systems, definiert als ISO/IEC 42010:2007. Legt einen (abstrakten) Rahmen für die Beschreibung von Softwarearchitekturen fest.

Siehe iterative und inkrementelle Entwicklung.

Verschiedene Bedeutungen:

Eines der grundlegenden Schutzziele, das die Aufrechterhaltung und Gewährleistung der Richtigkeit und Vollständigkeit der Daten bezeichnet. Dies wird üblicherweise durch den Einsatz von kryptografischen Algorithmen zur Erstellung einer digitalen Signatur erreicht.

Daten- oder Verhaltensintegrität:

Siehe auch Konsistenz.

international Software Architecture Qualification Board – eine international aktive Organisation zur Förderung der Entwicklung der Softwarearchitektur-Ausbildung. Siehe auch die Diskussion im Anhang.

Normen zur Beschreibung (und Bewertung) von Softwareproduktqualität. Das Qualitätsmodell legt fest, welche Qualitätseigenschaften bei der Bewertung der Eigenschaften eines Softwareprodukts berücksichtigt werden. (Übersetztes englisches Zitat von der ISO-Website)

Eine Liste der in der ISO 25010 Norm definierten Qualitätsmerkmale findet sich unter [ISO-25010].

(Veraltete) Norm zu Beschreibung (und Bewertung) von Softwareproduktqualität. Inzwischen abgelöst durch ISO 25010.

"Entwicklungsansatz, bei dem Entwicklungsphasen von der Zusammenstellung der Anforderungen bis zur Bereitstellung der Funktionalität in einem funktionierenden Release in Zyklen durchlaufen werden." (Übersetztes englisches Zitat von c2-wiki).

Diese Zyklen werden zur Verbesserung von Funktionalität, Qualität oder beidem wiederholt.

Gegensätzlich zur Wasserfall-Entwicklung.

Kombination von iterativen und inkrementellen Ansätzen zur Softwareentwicklung. Sie sind wesentliche Bestandteile verschiedener agiler Entwicklungsansätze, z.B. Scrum und XP.

Kapselung bezeichnet zwei leicht unterschiedliche Konzepte und manchmal eine Kombination der beiden:

Kapselung ist ein Mechanismus zum Verbergen von Informationen.

Beschreibt die quantitative Bewertung einer Assoziation oder Beziehung. Sie gibt die Zahl der Beteiligten (Objekte, Instanzen, Module usw.) der Assoziation an.

Eines der sechs kryptografischen Axiome, die 1883 von dem niederländischen Kryptografen und Linguisten Auguste Kerckhoffs in dem Artikel "La cryptographie militaire" beschrieben wurde. Dieses Axiom ist heute noch relevant und wird daher als "Kerckhoffs’sches Prinzip" bezeichnet.

Es schildert, dass eine kryptografische Methode nicht geheim gehalten werden muss, um die verschlüsselte Botschaft zu schützen.

"Der Feind kennt das System" ist ein weiterer Ausdruck, den der Mathematiker Claude Shannon als Shannons Maxime geprägt hat.

Siehe Bruce Schneiers Crypto-Gram, May 15, 2002

Eine Verarbeitungsressource (Ausführungsumgebung, Prozessor, Maschine, virtuelle Maschine, Anwendungsserver) zur Verteilung und Ausführung von Artefakten.

Maß, in dem Elemente eines Bausteins, einer Komponente oder eines Moduls zusammengehören wird Kohäsion genannt. Sie misst die Stärke der Beziehung zwischen Teilen einer Funktionalität in einer gegebenen Komponente. In kohärenten Systemen ist Funktionalität stark verbunden. Sie wird in der Regel als starke Kohäsion oder schwache Kohäsion charakterisiert. Ziel sollte starke Kohäsion sein, da diese oft mit Wiederverwendbarkeit, loser Kopplung und Verständlichkeit einhergeht.

Entwurfsmuster, bei dem ein Objekt zur Kapselung einer Aktion genutzt wird. Diese Aktion kann später aufgerufen oder ausgeführt werden.

"Komplexität wird im Allgemeinen zur Charakterisierung eines Systems o.Ä. mit vielen Teilen, in dem diese Teile auf unterschiedliche Weise miteinander interagieren, verwendet." (Übersetztes englisches Zitat aus Wikipedia.)

(Übersetztes englisches Zitat von Mark Needham)

Architekten haben sich um eine Verringerung der akzidentellen Komplexität zu bemühen.

Siehe Baustein. Strukturelement einer Architektur.

Kombination von einfacheren Elementen (z.B. Funktionen, Datentypen, Bausteinen) zu komplizierteren, leistungsstärkeren oder stärker verantwortlichen Elementen.

In UML: Wenn das enthaltende Element vernichtet wird, werden auch die enthaltenen Elemente vernichtet.

Ein konsistentes System enthält keine Widersprüche.

"Definiert die Beziehungen, Abhängigkeiten und Interaktionen zwischen dem System und seiner Umgebung: Menschen, Systeme und externe Entitäten, mit denen es interagiert." (Übersetztes englisches Zitat aus Rozanski-Woods)

Eine weitere Definition von arc42: "System Scope und Kontext - wie der Name schon sagt - grenzen dein System (d.h. deinen Scope) von all seinen Kommunikationspartnern (benachbarte Systeme und Benutzer, d.h. den Kontext deines Systems) ab. Er legt damit die externen Schnittstellen fest." (zitiert aus docs.arc42.org)

Unterscheide zwischen geschäftlichem und technischem Kontext:

Auch als Kontextsicht bezeichnet. Zeigt das vollständige System als eine Blackbox in seiner Umgebung. Dies kann entweder aus fachlicher Perspektive (fachlicher Kontext) und/oder aus technischer oder Verteilungsperspektive (technischer Kontext) erfolgen. Die Kontextabgrenzung (oder Kontextdiagramm) zeigt die Grenzen zwischen einem System und seiner Umgebung und stellt die Entitäten in seiner Umgebung (seine Nachbarn), mit denen es interagiert, dar.

Nachbarn können andere Software, Hardware (wie Sensoren), Menschen, Benutzerrollen oder sogar Organisationen, die das System nutzen, sein.

Siehe Kontext.

Kontextgrenze ist ein Prinzip des Strategieentwurfs von Domain-Driven Design. "Eine Kontextgrenze definiert ausdrücklich den Kontext, in dem ein Domänenmodell für ein Softwaresystem gilt. Idealerweise wäre ein einziges, einheitliches Modell für alle Systeme in derselben Domäne am besten. Dies ist zwar ein ehrenwertes Ziel, aber in Wirklichkeit ist es normalerweise in mehrere Modelle zerstückelt. Es ist sinnvoll, dies so hinzunehmen und damit zu arbeiten." (Übersetztes englisches Zitat aus Wikipedia)

"Bei sämtlichen großen Projekten gibt es mehrere Domänenmodelle. Doch wenn auf unterschiedlichen Modellen basierender Code miteinander kombiniert wird, wird die Software fehlerhaft, unzuverlässig und schwer verständlich. Die Kommunikation der Teammitglieder wird verwirrend. Es ist häufig unklar, in welchem Kontext ein Modell nicht angewandt werden sollte. Daher gilt: Legen Sie in Bezug auf Teamorganisation, Verwendung in spezifischen Teilen der Anwendung und physische Manifestationen, wie Codebasen oder Datenbankschemata, ausdrücklich Grenzen fest. Sorgen Sie dafür, dass das Modell exakt mit diesen Grenzen konsistent ist, aber lassen Sie sich nicht von Themen außerhalb ablenken oder verwirren." (Übersetztes englisches Zitat aus Wikipedia)

Plan, Prinzip(ien) oder Regel(n), wie ein spezifisches Problem zu lösen ist.

Konzepte sind häufig querschnittlich, in dem Sinne, dass mehrere Architekturelemente von einem einzigen Konzept betroffen sein können. Das heißt, dass Implementierer von z.B. Implementierungseinheiten (Bausteinen) das entsprechende Konzept einhalten sollen.

Konzepte bilden die Basis für konzeptionelle Integrität.

Konzepte, Regeln, Muster und ähnliche Lösungsansätze werden im gesamten System auf einheitliche (homogene, ähnliche) Weise angewendet. Ähnliche Probleme werden auf ähnliche oder identische Weise gelöst.

Kopplung ist die Art und der Grad der Interdependenz zwischen Software-Bausteinen; ein Maß dafür, wie eng zwei Komponenten verbunden sind.

Ziel sollte immer eine lose Kopplung sein. Kopplung steht in der Regel im Gegensatz zu Kohäsion. Lose Kopplung korreliert häufig mit starker Kohäsion. Lose Kopplung ist oft ein Zeichen für ein gut strukturiertes System. Zusammen mit starker Kohäsion unterstützt sie Verständlichkeit und Wartbarkeit.

Korrespondenz definiert eine Beziehung zwischen Architekturbeschreibungselementen. Korrespondenzen werden genutzt, um relevante Architekturbeziehungen innerhalb einer Architekturbeschreibung (oder zwischen Architekturbeschreibungen) auszudrücken (gemäß Definition in ISO/IEC/IEEE 42010).

Korrespondenzen können Korrespondenzregeln unterliegen. Korrespondenzregeln werden genutzt, um Beziehungen innerhalb einer Architekturbeschreibung (oder zwischen Architekturbeschreibungen) durchzusetzen (gemäß Definition in ISO/IEC/IEEE 42010).

Synonym: Integrität, Homogenität, konzeptionelle Integrität.

Latenz ist die zeitliche Verzögerung zwischen der Ursache und der Wirkung einer Veränderung in einem System.

In Computernetzwerken beschreibt die Latenz die Zeit, die eine Datenmenge (Paket) braucht, um von einem bestimmten Ort zu einem anderen zu gelangen.

In interaktiven Systemen ist die Latenz die Zeitspanne zwischen einer Eingabe in das System und der audiovisuellen Reaktion. Oft gibt es eine Verzögerung, die oft durch Netzwerkverzögerungen verursacht wird.

Zeigt die Zusammenarbeit von Bausteinen (beziehungsweise ihrer Instanzen) zur Laufzeit in konkreten Szenarien. Sollte auf Elemente der Bausteinsicht verweisen. Kann beispielsweise (muss aber nicht) als UML-Sequenz oder Aktivitätsdiagramm ausgedrückt werden.

Der Lernprozess, der von einer Schule angeboten wird (hier: iSAQB® als Institution, die für die Softwarearchitekturausbildung). Er umfasst den Inhalt der Kurse (den Lehrplan), die angewandten Methoden und andere Aspekte wie Normen und Werte, die sich auf die Art und Weise beziehen, wie die Ausbildung einschließlich Zertifizierung und Prüfung organisiert ist.

Bezieht sich auf die objektorientierte Programmierung: Wenn Vererbung genutzt wird, dann richtig: Instanzen von abgeleiteten Typen (Unterklassen) müssen vollständig an die Stelle ihrer Basistypen treten können. Wenn der Code Basisklassen verwendet, können diese Referenzen durch jede beliebige Instanz einer abgeleiteten Klasse ersetzt werden, ohne dass dies die Funktionalität des Codes beeinträchtigt.

Programm zur Erstellung von Zeichnungen, die in der Architekturdokumentation verwendet werden können. Beispiele: MS Visio, OmniGraffle, PowerPoint, etc. Mal-/Zeichenprogramme behandeln jede Zeichnung als separate Sache, was bei der Aktualisierung eines Elements der Architektur, das in mehreren Diagrammen erscheint, zu höheren Wartungskosten führt (anders als ein Modellierungswerkzeug).

Für Multi-Faktor-Authentifizierung siehe Authentifizierung.

Architekturstil, der die Unterteilung von großen Systemen in kleine Einheiten vorschlägt. "Microservices müssen als virtuelle Maschinen, als leichtere Alternativen, wie Docker-Container, oder als individuelle Prozesse implementiert werden. Dadurch können sie leicht einzeln in Produktion genommen werden." (Übersetztes englisches Zitat aus dem (kostenlosen) LeanPub booklet on Microservices von Eberhard Wolff.

Architekturmuster, das häufig zur Implementierung von Benutzeroberflächen verwendet wird. Unterteilt ein System in drei miteinander verbundene Teile (Modell / model, Präsentation / view und Steuerung / controller), um die folgenden Verantwortlichkeiten zu trennen:

Konventionen für einen Modellierungstyp (gemäß Definition in ISO/IEC/IEEE 42010).

Beispiele für Modellarten sind Datenflussdiagramme, Klassendiagramme, Petri-Netze, Bilanzen, Organigramme und Zustandsübergangsmodelle.

Modellgetriebene Architektur / Model Driven Architecture (MDA) ist ein OMG-Standard für die modellbasierte Softwareentwicklung. Definition: Ein Ansatz zur IT-Systemspezifikation, bei dem die Spezifikation der Funktionalität von der Spezifikation der Implementierung dieser Funktionalität auf einer spezifischen Technologieplattform getrennt wird.

Die zugrunde liegende Idee besteht darin, Code aus abstrakteren Anforderungsmodellen oder der Domäne zu generieren.

Ein Werkzeug, das Modelle erstellt (z.B. UML- oder BPMN-Modelle). Kann zur Erstellung von konsistenten Diagrammen zur Dokumentation verwendet werden, da es den Vorteil hat, dass jedes Modellelement nur einmal vorhanden ist, aber in vielen Diagrammen konsistent angezeigt wird (anders als bei einem einfachen Mal-/Zeichenprogramm).

(Siehe auch Modulare Programmierung)

"Softwareentwurfstechnik, die die Funktionalität eines Programms in unabhängige, austauschbare Module unterteilt, sodass jedes Modul alles enthält, was zur Ausführung von nur einem Aspekt der gewünschten Funktionalität erforderlich ist.

Module haben Schnittstellen, die die vom Modul bereitgestellten und benötigten Elemente angeben. Die in der Schnittstelle definierten Elemente können von anderen Modulen erkannt werden." (Übersetztes englisches Zitat aus Wikipedia)

Wiederverwendbare oder wiederholbare Lösung für ein gängiges Problem beim Softwareentwurf oder in der Softwarearchitektur.

Siehe Architekturmuster oder Entwurfsmuster.

Nebenläufigkeit ist die Möglichkeit, verschiedene Teile oder Einheiten eines Programms, Algorithmus oder Problems in beliebiger Reihenfolge oder in Teilreihenfolge auszuführen, ohne das Endergebnis zu beeinflussen. Aus Nebenläufigkeit folgt dabei nicht zwangsläufig Parallelität. (Übersetzung nach Wikipedia)

Da eine einzelne CA ein leichtes Ziel für einen Angreifer sein könnte, delegiert ein Netz des Vertrauens die Begründung des Vertrauens an den Benutzer. Jeder Benutzer entscheidet, in der Regel durch Überprüfung eines Fingerprints eines Schlüssels, welchem Identitätsnachweis anderer Nutzer er vertraut. Dieses Vertrauen wird durch die Signatur des Schlüssels des anderen Benutzers, der ihn dann mit der zusätzlichen Signatur veröffentlichen kann, ausgedrückt. Ein dritter Benutzer kann dann diese Signatur überprüfen und entscheiden, ob er der Identität vertraut oder nicht.

Die E-Mail-Verschlüsselung PGP ist ein Beispiel für eine auf einem Netz des Vertrauens basierende PKI.

Anforderungen, die die Lösung einschränken. Nichtfunktionale Anforderungen werden auch als Qualitätsanforderungen bezeichnet. Der Begriff nichtfunktional ist eigentlich irreführend, da viele der betreffenden Eigenschaften sich direkt auf spezifische Systemfunktionen beziehen, weshalb sie im modernen Anforderungsmanagements gerne als vorgegebene Randbedingungen bezeichnet werden.

In der modernen Webentwicklung: Kurz für die quelloffene JavaScript-Laufzeitumgebung Node.js®, die auf V8 JavaScript von Chrome aufbaut. Node.js ist für sein ereignisgesteuertes, nicht blockierendes E/A-Modell und sein großes Ökosystem unterstützender Bibliotheken bekannt.

Ein System aus Zeichen, Symbolen, Bildern oder Schriftzeichen zur Darstellung von Informationen. Beispiele: Fließtexte, Tabellen, Stichpunktlisten, nummeriere Listen, UML, BPMN.

Abhängigkeit zwischen zwei Bausteinen. Wenn A B nutzt, dann hängt die Ausführung von A von der Anwesenheit einer korrekten Implementierung von B ab.

Softwareentitäten (Klassen, Module, Funktionen usw.) sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein (Bertrand Meyer, 1998). Einfach gesagt: Um eine Funktionalität zu einem System hinzuzufügen (Erweiterung), sollte keine Modifikation des vorhandenen Codes erforderlich sein. Teil der "SOLID-"Prinzipien von Robert Martin für objektorientierte Systeme. Kann in objektorientierten Sprachen durch Schnittstellenvererbung, allgemeiner als Plugins, implementiert werden.

Das Open Web Application Security Project ist eine 2001 gegründete, weltweite, gemeinnützige Onlineorganisation zur Verbesserung der Softwaresicherheit. Es ist eine reichhaltige Quelle für Informationen und beste Praktiken im Bereich Websicherheit. Siehe https://www.owasp.org/.

Die OWASP-Top-10 ist eine häufig angeführte Liste von Angriffskategorien basierend auf der Datenerhebung des Projekts.

Grundsätze für die Gestaltung der Struktur von Softwaresystemen ([Martin-2003]):

Robert C. Martin, der das Akronym "SOLID" geprägt hat, hat auch die Packaging-Prinzipien eingeführt und häufig beide zusammen angeführt. Während die SOLID-Prinzipien auf die Klassenebene abzielen, beziehen sich die Packaging-Prinzipien auf die Ebene größerer Komponenten, die mehrere Klassen enthalten und eventuell unabhängig verteilt werden.

Package- und SOLID-Prinzipien haben beide das ausdrückliche Ziel, Software wartbar zu halten und die Anzeichen von schlechtem Design, Rigidität, Fragilität, Immobilität und Viskosität zu vermeiden.

Martin hat die Packaging-Prinzipien zwar bezogen auf große Komponenten formuliert, sie gelten jedoch auch für alle anderen Größen. Ihr Kern sind universelle Prinzipien, wie lose Kopplung, eindeutige Verantwortung, hierarchische (azyklische) Zerlegung und die Erkenntnis, dass sinnvolle Abhängigkeiten von spezifischen/instabilen Konzepten zu abstrakteren/stabileren verlaufen (was sich im DIP wiederfindet).

Eigenschaft eines kryptografischen Protokolls, die darin besteht, dass ein Angreifer durch Kompromittierung von Langzeitschlüsseln keine Informationen über Kurzzeit-Sitzungsschlüssel erhalten kann.

Beispiele für Protokolle mit perfekter vorwärts gerichteter Geheimhaltung sind TLS und OTR. Wenn diese Funktion für TLS aktiviert ist und ein Angreifer Zugriff auf den privaten Schlüssel erhält, können früher aufgezeichnete Kommunikationssitzungen dennoch nicht entschlüsselt werden.

Eine Perspektive dient der Berücksichtigung einer Reihe von zusammenhängenden Qualitätseigenschaften und Belangen eines Systems.

Architekten wenden Perspektiven iterativ auf die Architektursichten eines Systems an, um die Auswirkungen von Architekturentwurfsentscheidungen über mehrere Blickwinkel und Architektursichten hinweg zu beurteilen.

[Rozanski & Woods 2011] verbindet mit dem Begriff Perspektive auch Aktivitäten, Taktiken und Richtlinien, die zu berücksichtigen sind, wenn ein System eine Reihe von zusammenhängenden Qualitätseigenschaften erfüllen soll, und schlägt folgende Perspektiven vor:

Eine gelbliche mausähnliche Figur aus der (recht berühmten) Pokémon-Welt. Das brauchen Sie eigentlich nicht zu wissen. Aber es schadet auch nicht – und vielleicht beeindrucken Sie Ihre Kinder mit diesem Wissen…​

Verbindung im "Pipes und Filter"-Architekturstil, die Datenströme oder -blöcke von der Ausgabe eines Filters zur Eingabe eines anderen Filters überträgt, ohne Werte oder die Datenreihenfolge zu verändern.

Abkürzung von Public-Key-Infrastruktur. Ein Konzept zum Management von digitalen Zertifikaten, das üblicherweise asymmetrische Kryptografie nutzt. Der Begriff "public" (öffentlich) bezieht sich zumeist auf die Art des verwendeten Kryptografieschlüssels und nicht notwendigerweise auf eine öffentlich zugängliche Infrastruktur. Zur Vermeidung von Begriffsverwirrungen kann "offene PKI" oder "geschlossene PKI" verwendet werden, vgl. [Anderson-2008] Kapitel 21.4.5.7 PLI, Seite 672.

Eine PKI basiert in der Regel auf einer CA oder einem Netz des Vertrauens.

UML-Konstrukt, das in Komponentendiagrammen verwendet wird. Eine Schnittstelle, die einen Punkt, an dem eine Komponente mit ihrer Umgebung interagiert, definiert.

Pattern-oriented Software Architecture. Buchreihe zu Softwarearchitekturmustern.

Im Sicherheitskontext sind Principals Entitäten, die authentifiziert wurden und denen Berechtigungen zugewiesen werden können. Principals können Benutzer, aber auch andere Dienste oder ein auf einem System laufender Prozess sein. Der Begriff wird in der Java-Umgebung und in verschiedenen Authentifizierungsprotokollen verwendet (siehe GSSAPI RFC2744 oder Kerberos RFC4121).

Häufig in Verbindung mit Pseudozufallszahlengeneratoren verwendet. Die Erzeugung von Zufälligkeit mit hoher Entropie ist ressourcenintensiv und, abgesehen von Kryptografie, nicht für viele Anwendungen erforderlich. Zur Behebung dieses Problems werden Pseudozufallszahlengeneratoren mit einen Daten-Startwert initialisiert und erzeugen basierend auf diesem Startwert zufällige Werte. Die Daten werden zufällig erzeugt, aber sind immer gleich, wenn der Generator mit dem gleichen Startwert initialisiert wird. Dies wird als Pseudo-Zufälligkeit bezeichnet und ist weniger leistungsintensiv.

Erkennung von Risiken bezüglich der gewünschten Qualitätsmerkmale eines Systems. Analyse oder Beurteilung, ob ein System oder seine Architektur die gewünschten oder geforderten Qualitätsziele erreichen kann.

Statt mit der Berechnung oder Messung bestimmter Eigenschaften von Systemen oder Architekturen befasst sich die qualitative Bewertung mit Risiken, Kompromissen und Sensitivitätspunkten.

Siehe auch Beurteilung.

Siehe Softwarequalität und Qualitätsmerkmale.

Eigenschaft oder Merkmal einer Komponente eines Systems. Beispiele sind Laufzeitleistung, Schutz, Sicherheit, Zuverlässigkeit oder Wartbarkeit. Siehe auch Softwarequalität.

(Syn.: Qualitätsattributbaum). Ein hierarchisches Modell zur Beschreibung von Produktqualität: Die Wurzel "Qualität" wird hierarchisch in Bereiche oder Themen verfeinert, welche wiederum verfeinert werden. Qualitätsszenarien bilden die Blätter dieses Baums.

Synonym: Qualitätsmerkmal.

Die Softwarequalität ist das Maß, in dem ein System die gewünschte Kombination von Merkmalen besitzt. (Siehe: Softwarequalität).

In der ISO-25010 Norm sind folgende Qualitätsmerkmale definiert:

Es kann hilfreich sein, zwischen folgenden Typen von Merkmalen zu unterscheiden:

Beispiele für Laufzeitqualitätsmerkmale sind Leistungseffizienz, Sicherheit, Zuverlässigkeit, Benutzungsfreundlichkeit und Robustheit.

Beispiele für Nicht-Laufzeitqualitätsmerkmale sind Modifizierbarkeit, Portierbarkeit, Wiederverwendbarkeit und Testbarkeit.

Maß, in dem sich ein Produkt oder System effektiv und effizient an unterschiedliche oder sich weiterentwickelnde Hardware, Software oder sonstige Betriebs- oder Nutzungsumgebungen anpassen lässt. Teilmerkmal von: Portierbarkeit. Vgl. Website von ISO 25010.

Maß der Effektivität und Effizienz, mit dem die Auswirkung einer geplanten Änderung an einem oder mehreren seiner Teile auf ein Produkt oder System beurteilt, die Mängel oder Fehlerursachen eines Produkts diagnostiziert oder zu modifizierende Teile identifiziert werden können. Teilmerkmal von: Wartbarkeit. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt ein anderes spezifiziertes Softwareprodukt für den gleichen Zweck in der gleichen Umgebung ersetzen kann. Teilmerkmal von: Portierbarkeit. Vgl. Website von ISO 25010.

Maß, inwieweit nachgewiesen werden kann, dass die Identität eines Subjekts oder einer Ressource der Identitätsbehauptung entspricht. Teilmerkmal von: Sicherheit. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System Eigenschaften aufweist, die es einfach bedien- und steuerbar machen. Teilmerkmal von: Benutzerfreundlichkeit. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System von spezifizierten Benutzern effektiv, effizient, und zufriedenstellend zur Erreichung von spezifizierten Zielen in einem spezifizierten Nutzungskontext genutzt werden kann. Es besteht aus folgenden Teilmerkmalen: Erkennbarkeit der Brauchbarkeit, Erlernbarkeit, Bedienbarkeit, Schutz vor Fehlbedienung, Ästhetik der Benutzeroberfläche, Zugänglichkeit.

Vgl. Website von ISO 25010.

Maß, in dem Benutzer erkennen können, ob ein Produkt oder System für ihre Bedürfnisse geeignet ist. Teilmerkmal von: Benutzerfreundlichkeit. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System von spezifizierten Benutzern verwendet werden kann, um spezifizierte Lernziele zur Nutzung des Produkts oder Systems in einem spezifizierten Nutzungskontext effektiv, effizient, risikofrei und zufriedenstellend zu erreichen. Teilmerkmal von: Benutzerfreundlichkeit. Vgl. Website von ISO 25010.

Maß, in dem ein System, ein Produkt oder eine Komponente trotz Hardware- oder Softwarefehlern wie vorgesehen funktioniert. Teilmerkmal von: Zuverlässigkeit. Vgl. Website von ISO 25010.

Maß, in dem die Funktionen die Erfüllung von spezifizierten Aufgaben und Zielen ermöglichen. Teilmerkmal von: Funktionale Eignung. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System bei Nutzung unter spezifizierten Bedingungen Funktionen liefert, die festgelegte und vorausgesetzte Erfordernisse erfüllen. Es besteht aus folgenden Teilmerkmalen: funktionale Vollständigkeit, funktionale Korrektheit, funktionale Angemessenheit.

Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System die korrekten Ergebnisse mit dem benötigten Grad an Präzision liefert. Teilmerkmal von: Funktionale Eignung. Vgl. Website von ISO 25010.

Maß, in dem der Satz von Funktionen alle spezifizierten Aufgaben und Benutzerziele abdeckt. Teilmerkmal von: Funktionale Eignung. Vgl. Website von ISO 25010.

Maß der Effektivität und Effizienz, mit dem ein Produkt oder ein System in einer spezifizierten Umgebung erfolgreich installiert und/oder deinstalliert werden kann. Teilmerkmal von: Portierbarkeit. Vgl. Website von ISO 25010.

Maß, in dem ein System, ein Produkt oder eine Komponente den unbefugten Zugriff auf Computerprogramme oder Daten oder deren unbefugte Abänderung verhindert. Teilmerkmal von: Sicherheit. Vgl. Website von ISO 25010.

Maß, in dem zwei oder mehr Systeme, Produkte oder Komponenten Informationen austauschen und die ausgetauschten Informationen nutzen können. Teilmerkmal von: Kompatibilität. Vgl. Website von ISO 25010.

Maß, in dem die Höchstgrenzen eines Produkt- oder Systemparameters den Anforderungen entsprechen. Teilmerkmal von: Leistungseffizienz. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt, während es sich eine gemeinsame Umgebung und Ressourcen mit anderen Produkten teilt, ohne nachteilige Auswirkungen auf andere Produkte seine geforderten Funktionen effizient erfüllen kann. Teilmerkmal von: Kompatibilität. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt, ein System oder eine Komponente Informationen mit anderen Produkten, Systemen oder Komponenten austauschen und/oder ihre geforderten Funktionen erfüllen können, während sie sich eine Hardware- oder Softwareumgebung teilen. Es besteht aus folgenden Teilmerkmalen: Koexistenz Interoperabilität. Vgl. Website von ISO 25010.

Leistung im Verhältnis zur Menge der unter angegebenen Bedingungen genutzten Ressourcen.

Ressourcen können andere Softwareprodukte, die Software- und Hardwarekonfiguration des Systems und Materialien (z.B. Druckerpapier, Speichermedien) umfassen.

Es besteht aus folgenden Teilmerkmalen: Zeitverhalten, Ressourcenverbrauch, Kapazität. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System effektiv und effizient modifiziert werden kann, ohne dass Fehler eingebracht werden oder die bestehende Produktqualität beeinträchtigt wird. Teilmerkmal von: Wartbarkeit. Vgl. Website von ISO 25010.

Maß, inwieweit ein System oder Computerprogramm aus diskreten Komponenten besteht, sodass eine Änderung an einer Komponente minimale Auswirkungen auf andere Komponenten hat. Teilmerkmal von: Wartbarkeit. Vgl. Website von ISO 25010.

Maß, in dem nachgewiesen werden kann, dass Maßnahmen oder Ereignisse stattgefunden haben, so dass sie später nicht bestritten werden können. Teilmerkmal von: Sicherheit. Vgl. Website von ISO 25010.

Maß der Effektivität und Effizienz, mit dem ein System, ein Produkt oder eine Komponente von einer Hardware-, Software- oder sonstigen Betriebs- oder Nutzungsumgebung in eine andere übertragen werden kann. Es besteht aus folgenden Teilmerkmalen: Adaptierbarkeit, Installierbarkeit, Austauschbarkeit. Vgl. Website von ISO 25010.

Maß, in dem ein System, ein Produkt oder eine Komponente im Normalbetrieb die Zuverlässigkeitsanforderungen erfüllt. Teilmerkmal von: Zuverlässigkeit. Vgl. Website von ISO 25010.

Maß, in dem die von einem Produkt oder einem System bei der Erfüllung seiner Funktionen verbrauchten Mengen und Arten von Ressourcen den Anforderungen entsprechen. Teilmerkmal von: Leistungseffizienz. Vgl. Website von ISO 25010.

Maß, in dem ein System Benutzer davor schützt, Fehler zu machen. Teilmerkmal von: Benutzerfreundlichkeit.

Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System Informationen und Daten schützt, sodass Personen oder andere Produkte oder Systeme den ihren Berechtigungsarten oder -stufen entsprechenden Datenzugriffsgrad haben. Es besteht aus folgenden Teilmerkmalen: Vertraulichkeit, Integrität, Nichtabstreitbarkeit, Verantwortlichkeit, Authentifizierbarkeit. Vgl. Website von ISO 25010.

Maß an Effektivität und Effizienz, mit welchem Testkriterien für ein System, ein Produkt oder eine Komponente festgelegt und Tests durchgeführt werden können, um zu ermitteln, ob diese Kriterien erfüllt sind. Teilmerkmal von: Wartbarkeit. Vgl. Website von ISO 25010.

Maß, in dem Aktionen einer Entität eindeutig zu der Entität zurückverfolgt werden können. Teilmerkmal von: Sicherheit. Vgl. Website von ISO 25010.

Maß, in dem ein System, ein Produkt oder eine Komponente einsatzfähig und zugänglich sind, wenn sie benötigt werden. Teilmerkmal von: Zuverlässigkeit. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System sicherstellt, dass nur zugriffsberechtigte Zugriff auf die Daten haben. Teilmerkmal von: Sicherheit. Vgl. Website von ISO 25010.

Grad an Effektivität und Effizienz, mit dem ein Produkt modifiziert werden kann, um es zu verbessern, zu korrigieren oder an Veränderungen der Umgebung oder der Anforderungen anzupassen. Es besteht aus folgenden Teilmerkmalen: Modularität, Wiederverwendbarkeit, Analysierbarkeit, Modifizierbarkeit, Testbarkeit. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System im Falle einer Unterbrechung oder eines Fehlers die direkt betroffenen Daten und den gewünschten Systemstatus wiederherstellen kann. Teilmerkmal von: Zuverlässigkeit. Vgl. Website von ISO 25010.

Maß, in dem ein Asset in mehr als einem System oder zum Aufbau anderer Assets genutzt werden kann. Teilmerkmal von: Wartbarkeit. Vgl. Website von ISO 25010.

Maß, in dem die Antwort- und Verarbeitungszeiten und Durchsatzgeschwindigkeiten eines Produkts oder System bei der Erfüllung seiner Funktionen den Anforderungen entsprechen. Teilmerkmal von: Leistungseffizienz. Vgl. Website von ISO 25010.

Maß, in dem ein Produkt oder System von Personen mit einer großen Bandbreite von Eigenschaften und Fähigkeiten zur Erreichung eines spezifizierten Ziels in einem spezifizierten Nutzungskontext genutzt werden kann. Teilmerkmal von: Benutzerfreundlichkeit. Vgl. Website von ISO 25010.

Maß, in dem ein System, ein Produkt oder eine Komponente unter spezifizierten Bedingungen für eine spezifizierte Zeitdauer spezifizierte Funktionen erfüllt. Es besteht aus folgenden Teilmerkmalen: Reifegrad, Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit. Vgl. Website von ISO 25010.

Maß, in dem eine Benutzeroberfläche dem Benutzer eine angenehme und zufriedenstellende Interaktion ermöglicht. Teilmerkmal von: Benutzerfreundlichkeit.

Vgl. Website von ISO 25010.

(Aus ISO 25010) Ein Modell, das sich auf die statischen Eigenschaften von Software und die dynamischen Eigenschaften von Computersystemen und Softwareprodukten beziehende Qualitätseigenschaften definiert. Das Qualitätsmodell liefert eine konsistente Terminologie zur Spezifikation, Messung und Bewertung der System- und Softwareproduktqualität.

Der Anwendungsumfang von Qualitätsmodellen umfasst die Unterstützung der Spezifikation und Bewertung von Software und softwareintensiven Computersystemen aus unterschiedlichen Perspektiven durch an ihrem Erwerb, ihren Anforderungen, ihrer Entwicklung, ihrer Nutzung, ihrer Bewertung, ihrem Support, ihrer Wartung, ihrer Qualitätssicherung und -kontrolle sowie ihrem Audit beteiligte Personen.

(Syn.: quantitative Analyse): Messung oder Zählung von Werten von Softwareartefakten, z.B. Kopplung, zyklomatische Komplexität, Größe, Testabdeckung. Kennzahlen wie diese helfen bei der Identifizierung von kritischen Teilen oder Elementen von Systemen.

Funktionalität der Architektur oder des Systems, die mehrere Elemente betrifft. Beispiele für diese Belange sind Logging, Transaktionen, Sicherheit, Ausnahmebehandlung, Caching etc.

Siehe auch Konzept.

Siehe Konzept

Synonym: Prinzip, Regel.

Eine Rolle ist ein fester Satz an Berechtigungen, der üblicherweise einer Gruppe von Principals zugewiesen wird. So kann eine rollenbasierte Zugriffskontrolle zumeist effizienter umgesetzt werden als ein ACL-basiertes System und ermöglicht beispielsweise Vertreterreglungen.

Die Veränderung von Softwareeinheiten, sodass sie den gleichen Zweck wie zuvor erfüllen, jedoch auf andere Weise und gegebenenfalls mit anderen Mitteln. Häufig fälschlicherweise Refactoring genannt.

Begriff zur Bezeichnung der Verbesserung von Softwareeinheiten durch Veränderung ihrer internen Struktur ohne Veränderung des Verhaltens. (vgl.: "Refactoring ist der Prozess der Änderung eines Softwaresystems, sodass sich das externe Verhalten des Codes nicht verändert, aber die interne Struktur verbessert wird." – Refactoring, Martin Fowler, 1999)

Nicht mit Redesign zu verwechseln.

"Sehr bekanntes Objekt, das andere Objekte nutzen können, um gemeinsame Objekte und Dienste zu finden." (Übersetztes englisches Zitat PoEAA). Häufig als Singleton (auch ein bekanntes Entwurfsmuster) implementiert.

Ein Grundsatz für die Gestaltung der Struktur von Softwaresystemen (siehe auch Packaging-Prinzipien). Es verlangt einen "Release" und eine Versionskontrolle von großen Komponenten, insbesondere wenn das System sie von mehreren Punkten aus nutzt. Auch wenn sie nicht öffentlich herausgegeben werden, sollten diese Komponenten aus dem System extrahiert werden und durch einen externen Dependency Manager eine ordnungsgemäße Versionskontrolle erhalten.

Das REP enthält zwei unterschiedliche Erkenntnisse:

Einfach gesagt ist ein Risiko die Möglichkeit, dass ein Problem auftritt. Ein Risiko beinhaltet Ungewissheit über die Auswirkungen, Folgen oder Implikationen einer Aktivität oder Entscheidung, meist mit einer negativen Konnotation in Bezug auf einen bestimmten Wert (wie Gesundheit, Geld oder Eigenschaften eines Systems wie Verfügbarkeit oder Sicherheit).

Um ein Risiko zu quantifizieren, wird die Eintrittswahrscheinlichkeit mit dem potenziellen Wert multipliziert, der normalerweise ein Verlust ist – andernfalls wäre das Risiko eine Chance, die angesichts der Ungewissheit bei einigen Risiken ein mögliches Ergebnis sein könnte.

Reference Model for Open Distributed Processing

(Abstraktes) Metamodell zur Dokumentation von Informationssystemen. Definiert in ISO/IEC 10746.

"Konzept, gemäß dem an einem Modell sowie am aus diesem Modell generierten Code alle Arten von Änderungen vorgenommen werden können. Die Änderungen werden immer in beide Richtungen propagiert und beide Artefakte sind immer konsistent." (Übersetztes englisches Zitat aus Wikipedia).

Eine großartige Programmiersprache.

SOLID (Single-Responsibility, Open-Closed, Liskovsche Substitution, Interface-Segregation und Dependency-Inversion) ist ein (von Robert C. Martin) geprägtes Akronym für einige Prinzipien zur Verbesserung der objektorientierten Programmierung und des objektorientierten Entwurfs. Diese Prinzipien erhöhen die Wahrscheinlichkeit, dass ein Entwickler leicht zu wartenden und im Laufe der Zeit erweiterbaren Code schreibt.

Weitere Quellen: siehe [SOLID-principles].

Zusammenstellung von Bausteinen oder Komponenten die (zusammen) anderen Schichten einen kohärenten Satz an Services bieten. Die Beziehung zwischen Schichten wird durch die geordnete Beziehung erlaubt zu nutzen geregelt.

Mehrere Bedeutungen, je nach Kontext:

Ein Beispiel für die zweite Bedeutung ist das Programmiersprachenkonstrukt Interface aus der objektorientierten Sprache Java(tm):

Bausteine (Klassen, Komponenten) sollen nicht gezwungen werden, von Methoden abzuhängen, die sie nicht nutzen. Nach dem ISP werden größere Schnittstellen in kleinere und (client)spezifischere Schnittstellen aufgeteilt, sodass Clients nur Methoden kennen müssen, die sie tatsächlich nutzen.

Eine Organisation oder Person, die über die Rechte zur Nutzung von akkreditierten Schulungsunterlagen verfügt oder die eine Akkreditierung für Schulungsunterlagen erworben hat, Schulungsleiter und Infrastruktur zur Verfügung stellt und Schulungen durchführt.

Ein Trainer ist eine Person, die eine Schulung selbst leitet, mit der Maßgabe, dass diese im Rahmen einer einem akkreditierten Schulungsanbieter gewährten Akkreditierung durchgeführt wird. Entsprechend dürfen akkreditierte Schulungsanbieter nur CPSA®-Schulungen mit akkreditierten Schulungsleitern organisieren und durchführen. Nur akkreditierte Schulungsanbieter können Akkreditierungen von Schulungsleitern beantragen.

Das iSAQB® CPSA® Schulungsprogramm ist (derzeit) in zwei Schulungslevel gegliedert: Foundation Level und Advanced Level. Die Schulungslevel sollten aufeinander aufbauendes Wissen enthalten. Die genauen Beziehungen untereinander und die Inhalte dieser Schulungslevel sind in den jeweiligen Lehrplänen festgelegt.

Die Ziele sind der Hauptpunkt von Informationssicherheit. Sie sind ein Basissatz an Informationseigenschaften, die abhängig von der Architektur und den Prozessen eines Systems erfüllt werden können oder nicht.

Die gängigste Gruppe von vereinbarten Schutzzielen ist die sogenannte "CIA-Triade":

Das "Reference Model of Information Assurance and Security" (RMIAS) erweitert diese Liste um Verantwortlichkeit, Prüfbarkeit, Authentifizierbarkeit/Vertrauenswürdigkeit, Nichtabstreitbarkeit und Datenschutz.

Dies sind die typischen Beispiele für nichtfunktionale Anforderungen in Zusammenhang mit Sicherheit.

Siehe [Anderson-2008] Seite 11 oder [RMIAS-2013].

Ein Architekturstil, ähnlich wie Microservices. Auf scs-architecture.org heißt es hierzu (übersetzt aus dem Englischen):

"Der Ansatz Self-contained System (SCS) ist eine Architektur, die sich auf eine Trennung der Funktionalität in zahlreiche unabhängige Systeme konzentriert, sodass das vollständige System eine Zusammenarbeit vieler kleinerer Softwaresysteme ist. Dies verhindert das Problem großer Monolithen, die stetig wachsen und irgendwann nicht mehr wartbar sind."

Ein Secure-Development-Lifecycle ist der übliche Softwareentwicklungsprozess eines Unternehmens mit zusätzlichen Praktiken zur Entwicklung von sicherer Software. Er umfasst beispielsweise Code-Reviews, Architektur-Risikoanalysen, Blackbox/Whitebox und Penetrationstests und zahlreiche weitere Ergänzungen. Der SDL sollte den gesamten Lebenszyklus einer Anwendung, von den ersten Anforderungsmanagementaufgaben bis zum Feedback aus dem Betrieb der herausgegebenen Software durch Behebung von Sicherheitsproblemen, abdecken.

Siehe [McGraw-2006], Seite 239.

(In der qualitativen Bewertung, wie ATAM): Element des Architektursystems, das mehrere Qualitätsmerkmale beeinflusst. Wenn beispielsweise eine Komponente sowohl für die Laufzeitleistung als auch die Robustheit verantwortlich ist, ist diese Komponente ein Sensitivitätspunkt.

Salopp gesagt, wenn man einen Sensitivitätspunkt in den Sand setzt, hat man zumeist mehr als ein Problem.

Jedes Element einer Architektur sollte über Exklusivität und Einzigartigkeit von Verantwortlichkeit und Zweck verfügen: Kein Element sollte die Verantwortlichkeiten eines anderen Elements teilen oder unverbundene Verantwortlichkeiten enthalten.

Eine weitere Definition lautet: Aufteilung eines Systems in Elemente, die sich möglichst wenig überschneiden.

Der berühmte Edgar Dijkstra sagte 1974: "Separation of concerns …​ ist, auch wenn es nicht perfekt möglich ist, die einzig verfügbare Technik zur effektiven Ordnung der eigenen Gedanken."

Ähnlich wie das Single-Responsibility-Prinzip.

Diagrammart zur Illustration, wie Elemente einer Architektur interagieren, um ein bestimmtes Szenario zu erreichen. Es zeigt die Sequenz (Abfolge) von Mitteilungen zwischen Elementen. Die parallelen vertikalen Linien stellen die Lebensspanne von Objekten oder Komponenten dar, und die horizontalen Linien zeigen die Interaktionen zwischen diesen Komponenten. Siehe folgendes Beispiel.

Ein Service ist ein Baustein des Domain-driven Design. Services implementieren eine Logik oder Prozesse der Geschäftsdomäne, die nicht von Entitäten alleine ausgeführt werden. Ein Service ist zustandslos, und die Parameter und Rückgabewerte seiner Operationen sind Entitäten, Aggregate und Wertobjekte.

Siehe Architektursicht.

Signatur einer Funktion oder Methode: Siehe Funktionssignatur.

Digitale Signatur: Methode zur Überprüfung der Authentizität von Daten oder Dokumenten.

Jedes Element in einem System oder einer Architektur sollte eine einzige Verantwortlichkeit haben, und alle seine Funktionen oder Dienste sollten auf diese Verantwortlichkeit abgestimmt sein.

Kohäsion wird manchmal als gleichbedeutend mit SRP angesehen.

"Entwurfsmuster, das die Instanziierung einer Klasse auf ein Objekt beschränkt. Dies ist sinnvoll, wenn genau ein Objekt benötigt wird, um Aktionen im System zu koordinieren." (Übersetztes englisches Zitat aus Wikipedia.)

Es gibt mehrere(!) gültige und plausible Definitionen des Begriffs Softwarearchitektur. Die IEEE 1471 Norm schlägt folgende Definition vor:

In der neuen Norm ISO/IEC/IEEE 42010:2011 wurden die Definitionen folgendermaßen übernommen und überarbeitet:

Die Schlüsselbegriffe dieser Definition bedürfen einer Erläuterung:

Das Software Engineering Institute führt eine Sammlung weiterer Definitionen.

Auch wenn der Begriff sich oft auf die Softwarearchitektur eines IT-Systems bezieht, wird er auch benutzt, um sich auf Softwarearchitektur als Ingenieursdisziplin zu beziehen.

(Aus der IEEE-Norm 1061): Die Softwarequalität ist das Maß, in dem eine Software eine gewünschte Kombination von Merkmalen besitzt. Die gewünschte Kombination von Eigenschaften muss klar definiert sein; ansonsten bleibt die Beurteilung der Qualität der Intuition überlassen.

(Aus der ISO/IEC-Norm 25010): Die Qualität eines Systems ist das Maß, in dem das System die festgelegten und vorausgesetzten Anforderungen seiner verschiedenen Stakeholder erfüllt und somit Wert bietet. Diese festgelegten und vorausgesetzten Anforderungen sind in den ISO 25000 Qualitätsmodellen dargestellt, die Produktqualität in Eigenschaften, welche in manchen Fällen weiter in Untereigenschaften unterteilt werden, einteilt.

Wirtschaftlich, einfach, schlank oder mit relativ geringem Aufwand machbar sein.

Ein Grundsatz für die Gestaltung der Struktur von Softwaresystemen (siehe auch Packaging-Prinzipien). Er fordert, dass die Abstraktheit von Komponenten proportional zu ihrer Stabilität ist. Das eng damit verbundene SDP erklärt auch den Begriff Stabilität in diesem Zusammenhang.

Wir wollen, dass Komponenten, die abstrakte Konzepte und Verantwortlichkeiten repräsentieren, wenig oder keine Änderungen benötigen, weil zahlreiche konzeptionell spezifischere (konkrete) Komponenten von ihnen abhängen. Und wir wollen, dass Komponenten, die nicht einfach geändert werden können oder sollten, mindestens so abstrakt sind, dass wir sie erweitern können. Dies steht mit dem OCP in Zusammenhang.

Das SAP kann wie ein Zirkelargument klingen, bis die zugrunde liegende Idee zu Tage tritt: Konkrete Dinge und Konzepte sind natürlich volatiler, spezifischer, willkürlicher und zahlreicher als abstrakte. Die Komponentenstruktur eines Systems sollte dies einfach widerspiegeln. Die allgemeine Logik, die physischen Artefakte des Systems sowie seine funktionalen und technischen Konzepte sollten alle Deckungsgleich sein.

Das SAP ist eng mit dem SDP verbunden. Ihre Kombination ergibt eine allgemeinere und wohl tiefergehende Version des DIP: Spezifische Konzepte hängen natürlich von abstrakteren ab, da sie aus universaleren Bausteinen bestehen oder davon abgeleitet sind. Und abhängige Konzepte sind natürlich spezifischer, weil sie durch mehr Informationen als ihre Abhängigkeiten definiert sind (vorausgesetzt es gibt keine Abhängigkeitszyklen).

Ein Grundsatz für die Gestaltung der Struktur von Softwaresystemen (siehe auch Packaging-Prinzipien). Er fordert, dass sich häufig ändernde Komponenten von stabileren abhängen.

Ein Teil der Volatilität einer Komponente wird erwartet und von ihrer speziellen Verantwortlichkeit logischerweise impliziert.

Aber in diesem Kontext hängt Stabilität auch von ein- und ausgehenden Abhängigkeiten ab. Eine Komponente, von der andere stark abhängen, ist schwieriger zu ändern und gilt als stabiler. Eine Komponente, die stark von anderen abhängt, hat mehr Änderungsgründe und gilt als weniger stabil.

In Bezug auf Abhängigkeit sollte also eine Komponente mit vielen Clients nicht von einer Komponente mit vielen Abhängigkeiten abhängen. Eine einzelne Komponente, die diese beiden Eigenschaften auf sich vereint, ist ebenfalls eine Red Flag. Eine solche Komponente hat viele Gründe für eine Änderung, ist aber gleichzeitig schwer zu ändern.

Ursprüngliche Definitionen des SDP (wie [Martin-2003]) beinhalten eine Kennzahl I der Instabilität. Leider erfasst diese Kennzahl beabsichtigte/inhärente Volatilität, transitive Abhängigkeit oder Fälle, wie die oben genannte Red Flag, nicht. Aber wir wissen das Konzept des SDP zu schätzen, unabhängig davon, wie es sich messen lässt.

Das SDP ist eng mit dem SAP verbunden. Ihre Kombination ergibt eine allgemeinere Version des DIP (mehr dazu unter SAP).

Person oder Organisation, die von einem System, seiner Entwicklung oder Ausführung betroffen sein kann oder ein Interesse (stake) daran hat.

Beispiele sind Benutzer, Beschäftigte, Eigner, Administratoren, Entwickler, Entwerfer, Manager, Product Owner, Projektmanager.

Gemäß ISO/IEC/IEEE 42010 sind Stakeholder (System) eine Einzelperson, ein Team, eine Organisation oder Klassen davon, die ein Interesse an einem System haben (gemäß Definition in ISO/IEC/IEEE 42010).

(Entwurfsmuster) "Ein Wrapper oder Stellvertreterobjekt, das vom Client aufgerufen wird, um auf das reale Serving-Objekt im Hintergrund zuzugreifen. Die Funktion des Stellvertreters kann einfach in der Weiterleitung an das reale Objekt oder die Bereitstellung zusätzlicher Logik sein. Im Stellvertreter kann eine zusätzliche Funktionalität bereitgestellt werden, beispielsweise Caching, wenn die Operationen des realen Objekts ressourcenintensiv sind, oder Überprüfung von Voraussetzungen vor dem Aufruf von Operationen des realen Objekts. Für den Client ist die Verwendung eines Stellvertreterobjekts mit der Verwendung des realen Objekts vergleichbar, da beide die gleiche Schnittstelle implementieren." (Übersetztes englisches Zitat aus Wikipedia)

Anordnung, Ordnung oder Organisation von zusammenhängenden Elementen in einem System. Strukturen bestehen aus Bausteinen (Strukturelementen) und ihren Beziehungen (Abhängigkeiten).

In der Softwarearchitektur werden Strukturen häufig in Architektursichten, z.B. der Bausteinsicht, verwendet. Ein Dokumentationstemplate (z.B. arc42) ist auch eine Art Struktur.

Siehe Baustein oder Komponente

Symmetrische Kryptografie basiert auf einem identischen Schlüssel für die Verschlüsselung und Entschlüsselung von Daten. Sender und Empfänger vereinbaren einen Schlüssel für die Kommunikation. Siehe [Schneier, Bruce], Seite 17.

Sammlung von Elementen (Bausteinen, Komponenten usw.), die zu einem gemeinsamen Zweck organisiert sind. In den ISO/IEC/IEEE-Normen gibt es eine Reihe von Systemdefinitionen:

Qualitätsszenarien dokumentieren die vorgegebenen Qualitätsmerkmale. Sie helfen bei der Beschreibung der vorgegebenen oder gewünschten Eigenschaften eines Systems auf pragmatische und informelle Weise und machen dennoch das abstrakte Konzept "Qualität" konkret und greifbar.

Üblicherweise werden Qualitätsszenarien in drei Kategorien unterteilt

Zeigt das vollständige System als eine Blackbox innerhalb seiner Umgebung aus einer technischen bzw. Verteilungsperspektive. Dazu gehören insbesondere technische Schnittstellen und Kommunikationskanäle sowie die relevanten technischen Details der Nachbarsysteme. Damit ergänzt der technische Kontext den fachlichen Kontext um die Zuordnung der fachlichen Interaktionen mit Nachbarsystemen zu z. B. spezifischen Kommunikationskanälen und technischen Protokollen.

Siehe Kontextabgrenzung.

Standardisierte Zusammenstellung von Artefakten, die in der Softwareentwicklung verwendet werden. Templates können dabei helfen, andere Dateien, insbesondere Dokumente, in eine vordefinierte Struktur einzubetten, ohne den Inhalt dieser einzelnen Dateien vorzugeben.

Ein sehr bekanntes Template ist arc42

Transport-Layer-Security (Transportschichtsicherheit) bezeichnet eine Reihe von Protokollen zum kryptografischen Schutz der Kommunikation von zwei Parteien mit den Mitteln der CIA-Triade. Es wird sehr häufig zur sicheren Kommunikation im Internet genutzt und bildet die Grundlage für HTTPS.

TLS begann als Update seines Vorgängers SSL (Secure Socket Layer) Version 3.0 und sollte nun statt SSL verwendet werden siehe RFC7568 "Deprecating Secure Sockets Layer Version 3.0".

The Open Group Architecture Framework

Konzeptioneller Rahmen für die Planung und Wartung von Unternehmens-IT-Architekturen.

"Arbeitsrichtung" oder "Kommunikationsabfolge": Ausgehend von einem abstrakten oder allgemeinen Konstrukt hin zu einer konkreteren, spezielleren oder detaillierteren Darstellung.

(System) Kontext, der das Setting und die Umstände aller Einflüsse auf ein System bestimmt (gemäß Definition in ISO/IEC/IEEE 42010).

Die Umgebung eines Systems schließt Entwicklungs-, Geschäfts- und Betriebseinflüsse sowie technologische, organisatorische, politische, wirtschaftliche, rechtliche, regulatorische, ökologische und soziale Einflüsse ein.

Unified Modeling Language / Vereinheitlichte Modellierungssprache (UML)

Grafische Sprache zur Visualisierung, Spezifizierung und Dokumentation der Artefakte und Strukturen eines Softwaresystems.

Test der kleinsten testbaren Teile eines Systems, um festzustellen, ob sie einsatzfähig sind.

Je nach Implementierungstechnologie kann eine Unit eine Methode, Funktion, Schnittstelle oder ein ähnliches Element sein.

Synonym: Unternehmensarchitektur.

Strukturen und Konzepte für den IT-Support eines gesamten Unternehmens. Die kleinsten betrachteten Einheiten der Unternehmensarchitektur sind einzelne Softwaresysteme, auch "Anwendungen" genannt.

Ein grundlegendes Prinzip im Softwareentwurf: Entwurfs- oder Implementierungsentscheidungen, die sich wahrscheinlich ändern, werden verborgen gehalten, so dass andere Teile des Systems vor Modifizierungen geschützt sind, wenn diese Entscheidungen oder Implementierungen geändert werden. Eine der wichtigen Eigenschaften von Blackboxen. Trennt Schnittstelle von Implementierung.

Der Begriff Kapselung wird häufig austauschbar mit Verbergen von Informationen verwendet.

(Genauer gesagt: Anforderungsverfolgbarkeit): Dokumentation, dass

Meine persönliche Meinung: Verfolgbarkeit sollte nach Möglichkeit vermieden werden, da sie einen erheblichen Dokumentationsaufwand verursacht.

Eines der grundlegenden Schutzziele, das ein System beschreibt, das die gewünschten Informationen bei Bedarf bereitstellen kann. Aus einer Sicherheitsperspektive können beispielsweise Denial-of-Service-Angriffe die Verfügbarkeit verhindern.

Einbringen der Software in ihre Ausführungsumgebung (Hardware, Prozessor usw.). Inbetriebnahme der Software.

Architektursicht, die die technische Infrastruktur, in der ein System oder Artefakte verteilt und ausgeführt werden, zeigt.

"Diese Sicht definiert die physische Umgebung, in der das System laufen soll, einschließlich der Hardwareumgebung, die Ihr System benötigt (z.B. Verarbeitungsknoten, Netzwerkverbindungen und Speicherkapazitäten), der technischen Umgebungsanforderungen für jeden Knoten (oder Knotentyp) im System und des Mappings Ihrer Softwareelemente in Bezug auf die Laufzeitumgebung, die sie ausführt." (Übersetztes englisches Zitat von Rozanski+2011)

Eines der grundlegenden Schutzziele, das ein System beschreibt, welches Informationen nur Befugten offenlegt und bereitstellt.

Entwicklungsansatz, "bei dem man alle Anforderungen vorab zusammenträgt, den gesamten erforderlichen Entwurf bis runter auf Detailebene macht und dann die Spezifikationen an die Coder, die den Code schreiben, weitergibt; dann werden Tests durchgeführt (eventuell mit einem Abstecher in die Integrationshölle) und schließlich wird das Ganze mit einem großen abschließenden Release geliefert. Alles ist groß, auch die Gefahr des Scheiterns." (Übersetztes englisches Zitat aus C2 wiki.

Siehe auch iterativen Entwicklung

zu erledigen

Ein Wertobjekt ist ein Baustein des Domain-driven Designs. Wertobjekte haben keine eigene konzeptionelle Identität und sollten als unveränderlich behandelt werden. Sie werden zur Beschreibung des Zustands von Entitäten genutzt und können aus anderen Wertobjekten, aber niemals aus Entitäten bestehen.

Zeigt die interne Struktur eines aus Blackboxes bestehenden Systems oder Bausteins und die internen/externen Beziehungen/Schnittstellen.

Siehe auch Blackbox.

"Bietet eine Infrastruktur für die Einrichtung, Durchführung und Überwachung einer festgelegten Abfolge von Aufgaben in Form eines Workflows." (Übersetztes englisches Zitat aus Wikipedia)

(Syn.: Decorator, Adapter, Gateway) Muster zum abstrahieren der konkreten Schnittstelle oder Implementierung oder Komponente. Wrapper fügen zusätzliche Verantwortlichkeiten dynamisch zu einem Objekt hinzu.

Es gibt unterschiedliche Interpretationen aus verschiedenen Quellen. Zeitliche Kopplung

(Syn.: Faktorisieren) Aufbrechen oder Unterteilen eines komplexen Systems oder Problems in mehrere kleinere Teile, die einfacher zu verstehen, zu implementieren oder zu warten sind.

Das iSAQB® CPSA®-Zertifizierungsprogramm, einschließlich seiner organisatorischen Komponenten, Dokumente (Schulungsunterlagen, Verträge) und Prozesse.

Die urheberrechtliche geschützte Abkürzung CPSA® steht für Certified Professional for Software Architecture.

Siehe Entropie oder Pseudo-Zufälligkeit.

Quantitatives Maß, Zahl der unabhängigen Pfade durch den Quellcode eines Programms. Sie entspricht grob der Zahl der bedingten Anweisungen (if, while) im Code +1. Eine lineare Abfolge von Anweisungen ohne if oder while hat eine zyklomatische Komplexität von 1. Viele Softwareentwickler sind der Auffassung, dass eine höhere Komplexität mit der Anzahl der Fehler zusammenhängt.