Komponentenbasierte Architektur
Die komponentenbasierte Architektur konzentriert sich auf die Zerlegung des Entwurfs in einzelne funktionale oder logische Komponenten, die genau definierte Kommunikationsschnittstellen darstellen, die Methoden, Ereignisse und Eigenschaften enthalten. Es bietet eine höhere Abstraktionsebene und unterteilt das Problem in Unterprobleme, die jeweils Komponentenpartitionen zugeordnet sind.
Das Hauptziel der komponentenbasierten Architektur ist die Sicherstellung component reusability. Eine Komponente kapselt die Funktionalität und das Verhalten eines Softwareelements in einer wiederverwendbaren und selbst bereitstellbaren Binäreinheit. Es gibt viele Standardkomponenten-Frameworks wie COM / DCOM, JavaBean, EJB, CORBA, .NET, Webdienste und Grid-Dienste. Diese Technologien werden häufig im Design lokaler Desktop-GUI-Anwendungen verwendet, z. B. grafische JavaBean-Komponenten, MS ActiveX-Komponenten und COM-Komponenten, die durch einfaches Ziehen und Ablegen wiederverwendet werden können.
Komponentenorientiertes Software-Design bietet viele Vorteile gegenüber herkömmlichen objektorientierten Ansätzen wie -
Reduzierte Zeit auf dem Markt und Entwicklungskosten durch Wiederverwendung vorhandener Komponenten.
Erhöhte Zuverlässigkeit durch Wiederverwendung der vorhandenen Komponenten.
Was ist eine Komponente?
Eine Komponente ist ein modularer, portabler, austauschbarer und wiederverwendbarer Satz klar definierter Funktionen, die ihre Implementierung kapseln und als übergeordnete Schnittstelle exportieren.
Eine Komponente ist ein Softwareobjekt, das mit anderen Komponenten interagieren und bestimmte Funktionen oder eine Reihe von Funktionen einschließen soll. Es hat eine offensichtlich definierte Schnittstelle und entspricht einem empfohlenen Verhalten, das allen Komponenten innerhalb einer Architektur gemeinsam ist.
Eine Softwarekomponente kann als Kompositionseinheit mit einer vertraglich festgelegten Schnittstelle und nur expliziten Kontextabhängigkeiten definiert werden. Das heißt, eine Softwarekomponente kann unabhängig bereitgestellt werden und unterliegt der Zusammensetzung durch Dritte.
Ansichten einer Komponente
Eine Komponente kann drei verschiedene Ansichten haben - objektorientierte Ansicht, konventionelle Ansicht und prozessbezogene Ansicht.
Object-oriented view
Eine Komponente wird als eine Gruppe von einer oder mehreren kooperierenden Klassen angesehen. Jede Problemdomänenklasse (Analyse) und Infrastrukturklasse (Design) wird erläutert, um alle Attribute und Operationen zu identifizieren, die für ihre Implementierung gelten. Dazu gehört auch die Definition der Schnittstellen, über die Klassen kommunizieren und zusammenarbeiten können.
Conventional view
Es wird als Funktionselement oder Modul eines Programms angesehen, das die Verarbeitungslogik, die zur Implementierung der Verarbeitungslogik erforderlichen internen Datenstrukturen und eine Schnittstelle integriert, über die die Komponente aufgerufen und Daten an sie übergeben werden können.
Process-related view
In dieser Ansicht erstellt das System nicht jede Komponente von Grund auf neu, sondern baut auf vorhandenen Komponenten auf, die in einer Bibliothek verwaltet werden. Bei der Formulierung der Softwarearchitektur werden Komponenten aus der Bibliothek ausgewählt und zum Auffüllen der Architektur verwendet.
Eine Benutzeroberflächenkomponente (UI) enthält Raster, Schaltflächen, die als Steuerelemente bezeichnet werden, und Dienstprogrammkomponenten stellen eine bestimmte Teilmenge von Funktionen bereit, die in anderen Komponenten verwendet werden.
Andere gängige Arten von Komponenten sind ressourcenintensiv, auf die nicht häufig zugegriffen wird und die mithilfe des Just-in-Time-Ansatzes (JIT) aktiviert werden müssen.
Viele Komponenten sind unsichtbar und werden in Unternehmensanwendungen und Internet-Webanwendungen wie Enterprise JavaBean (EJB), .NET-Komponenten und CORBA-Komponenten verteilt.
Eigenschaften von Bauteilen
Reusability- Komponenten sind normalerweise so konzipiert, dass sie in verschiedenen Situationen in verschiedenen Anwendungen wiederverwendet werden können. Einige Komponenten können jedoch für eine bestimmte Aufgabe ausgelegt sein.
Replaceable - Komponenten können frei durch andere ähnliche Komponenten ersetzt werden.
Not context specific - Komponenten sind für den Betrieb in verschiedenen Umgebungen und Kontexten ausgelegt.
Extensible - Eine Komponente kann von vorhandenen Komponenten erweitert werden, um neues Verhalten bereitzustellen.
Encapsulated - Die AA-Komponente zeigt die Schnittstellen, über die der Aufrufer seine Funktionalität nutzen kann, und legt keine Details der internen Prozesse oder interne Variablen oder Zustände offen.
Independent - Komponenten sind so konzipiert, dass sie nur minimale Abhängigkeiten von anderen Komponenten aufweisen.
Prinzipien des komponentenbasierten Designs
Ein Entwurf auf Komponentenebene kann mithilfe einer Zwischendarstellung (z. B. grafisch, tabellarisch oder textbasiert) dargestellt werden, die in Quellcode übersetzt werden kann. Das Design von Datenstrukturen, Schnittstellen und Algorithmen sollte den etablierten Richtlinien entsprechen, um die Einführung von Fehlern zu vermeiden.
Das Softwaresystem wird in wiederverwendbare, zusammenhängende und gekapselte Komponenteneinheiten zerlegt.
Jede Komponente verfügt über eine eigene Schnittstelle, die die erforderlichen und bereitgestellten Ports angibt. Jede Komponente verbirgt ihre detaillierte Implementierung.
Eine Komponente sollte erweitert werden, ohne dass interne Code- oder Designänderungen an den vorhandenen Teilen der Komponente vorgenommen werden müssen.
Abhängig von Abstraktionskomponenten hängen sie nicht von anderen konkreten Komponenten ab, was die Schwierigkeit der Verbrauchbarkeit erhöht.
Konnektoren verbinden Komponenten und spezifizieren und regeln die Interaktion zwischen Komponenten. Der Interaktionstyp wird durch die Schnittstellen der Komponenten angegeben.
Die Komponenteninteraktion kann in Form von Methodenaufrufen, asynchronen Aufrufen, Broadcasting, nachrichtengesteuerten Interaktionen, Datenstromkommunikation und anderen protokollspezifischen Interaktionen erfolgen.
Für eine Serverklasse sollten spezielle Schnittstellen erstellt werden, um Hauptkategorien von Clients zu bedienen. In der Schnittstelle sollten nur die Vorgänge angegeben werden, die für eine bestimmte Kategorie von Clients relevant sind.
Eine Komponente kann auf andere Komponenten ausgedehnt werden und bietet dennoch eigene Erweiterungspunkte. Es ist das Konzept einer Plug-in-basierten Architektur. Dadurch kann ein Plugin eine andere Plugin-API anbieten.
Entwurfsrichtlinien auf Komponentenebene
Erstellt eine Namenskonvention für Komponenten, die als Teil des Architekturmodells angegeben werden, und verfeinert oder arbeitet sie dann als Teil des Modells auf Komponentenebene aus.
Ruft Namen von Architekturkomponenten aus der Problemdomäne ab und stellt sicher, dass sie für alle Beteiligten, die das Architekturmodell anzeigen, von Bedeutung sind.
Extrahiert die Geschäftsprozessentitäten, die unabhängig voneinander existieren können, ohne dass eine Abhängigkeit von anderen Entitäten besteht.
Erkennt und entdeckt diese unabhängigen Entitäten als neue Komponenten.
Verwendet Namen von Infrastrukturkomponenten, die ihre implementierungsspezifische Bedeutung widerspiegeln.
Modelliert alle Abhängigkeiten von links nach rechts und die Vererbung von oben (Basisklasse) nach unten (abgeleitete Klassen).
Modellieren Sie alle Komponentenabhängigkeiten als Schnittstellen, anstatt sie als direkte Abhängigkeit von Komponente zu Komponente darzustellen.
Entwurf auf Komponentenebene durchführen
Erkennt alle Entwurfsklassen, die der im Analysemodell und im Architekturmodell definierten Problemdomäne entsprechen.
Erkennt alle Entwurfsklassen, die der Infrastrukturdomäne entsprechen.
Beschreibt alle Entwurfsklassen, die nicht als wiederverwendbare Komponenten erfasst wurden, und gibt Nachrichtendetails an.
Identifiziert geeignete Schnittstellen für jede Komponente und erarbeitet Attribute und definiert Datentypen und Datenstrukturen, die für deren Implementierung erforderlich sind.
Beschreibt den Verarbeitungsablauf innerhalb jeder Operation im Detail anhand von Pseudocode- oder UML-Aktivitätsdiagrammen.
Beschreibt persistente Datenquellen (Datenbanken und Dateien) und identifiziert die Klassen, die für deren Verwaltung erforderlich sind.
Entwickeln und erarbeiten Sie Verhaltensrepräsentationen für eine Klasse oder Komponente. Dies kann durch Ausarbeiten der für das Analysemodell erstellten UML-Zustandsdiagramme und durch Untersuchen aller für die Entwurfsklasse relevanten Anwendungsfälle erfolgen.
Entwickelt Bereitstellungsdiagramme, um zusätzliche Implementierungsdetails bereitzustellen.
Demonstriert die Position von Schlüsselpaketen oder Komponentenklassen in einem System mithilfe von Klasseninstanzen und unter Angabe einer bestimmten Hardware- und Betriebssystemumgebung.
Die endgültige Entscheidung kann unter Verwendung etablierter Gestaltungsprinzipien und -richtlinien getroffen werden. Erfahrene Designer prüfen alle (oder die meisten) alternativen Designlösungen, bevor sie sich für das endgültige Designmodell entscheiden.
Vorteile
Ease of deployment - Wenn neue kompatible Versionen verfügbar werden, ist es einfacher, vorhandene Versionen zu ersetzen, ohne dass dies Auswirkungen auf die anderen Komponenten oder das gesamte System hat.
Reduced cost - Durch die Verwendung von Komponenten von Drittanbietern können Sie die Kosten für Entwicklung und Wartung verteilen.
Ease of development - Komponenten implementieren bekannte Schnittstellen, um definierte Funktionen bereitzustellen, die eine Entwicklung ermöglichen, ohne andere Teile des Systems zu beeinträchtigen.
Reusable - Durch die Verwendung wiederverwendbarer Komponenten können die Entwicklungs- und Wartungskosten auf mehrere Anwendungen oder Systeme verteilt werden.
Modification of technical complexity - Eine Komponente ändert die Komplexität durch die Verwendung eines Komponentencontainers und seiner Dienste.
Reliability - Die Gesamtsystemzuverlässigkeit steigt, da die Zuverlässigkeit jeder einzelnen Komponente die Zuverlässigkeit des gesamten Systems durch Wiederverwendung erhöht.
System maintenance and evolution - Einfache Änderung und Aktualisierung der Implementierung, ohne den Rest des Systems zu beeinträchtigen.
Independent- Unabhängigkeit und flexible Konnektivität von Komponenten. Unabhängige Entwicklung von Komponenten durch verschiedene Gruppen parallel. Produktivität für die Softwareentwicklung und zukünftige Softwareentwicklung.