Freitag, 16. August 2013

Von den Funktionsgruppen zu logischen Komponenten

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil Von den Funktionsgruppen zu logischen Komponenten.
3. Teil Von der logischen Komponente zur technischen Komponente.


Im letzten Post dieser Reihe ist eine Möglichkeit beschrieben worden, Funktionalität in weitere Funktionsgruppen zu bündeln. Des Weiteren konnten wir Funktionsgruppen mit Hilfe von Funktionsgruppen in einer Hierarchie ordnen. Funktionsgruppen einer bestimmten Ebene können wir dabei als funktionale Komponenten auffassen. Stellen wir uns eine Software vor, in der man bestimmte Testuntersuchungen ausführen möchte. Die gesamte Funktionalität des Erstellens dieser Tests wird in einer Funktionsgruppe konzentriert, Testausführung und Testauswertung sind weitere Funktionsgruppen.

Die logische Architektur „definiert Strukturen über Schichten und Komponenten sowie deren Hierarchie- und Kommunikationsbeziehungen, jedoch ohne Einzelheiten zur Implementierung und technischen Infrastruktur festzulegen.“ [S.348, REUS09] Die logisch motivierten Komponenten werden dabei mit Schnittstellen ausgestattet, über die sie kommunizieren. Das Auffinden der logischen Komponenten gelingt mit Hilfe von Schichtenmodellen und Software-Kategorien für Komponenten.

Anhand der verschiedenen Schichtenmodelle finden wir neue Grenzen, welche die funktionsgetriebenen Komponenten weiter unterteilen. Im Englischen unterscheiden wir Tiers und Layers.

"Ein Layer ist eine Trennlinie zwischen Bestandteilen der Anwendung, die die Anwendung in Komponenten einteilt. Diese Komponenten bestehen aus sinnvoll zusammengehörender Funktionalität. Idealerweise dürfen nur benachbarte Schichten (Layers) miteinander kommunizieren. Zwischen den Schichten ausgetauschte Datentransferobjekte sollten keine Logik enthalten und sie sollten gegebenenfalls den Bedürfnissen der nächsten Schicht angepasst werden. Dazu kann eine Adapterschicht notwendig werden." [BAU06]

"Eine Tier bezeichnet eine Prozessgrenze. Diese Grenze verläuft zwischen Programmen (Server, Browser, DBMS) oder zwischen Maschinen." [BAU06]

Nachdem wir mit Hilfe von Layern und Tiers neue Grenzen gefunden haben, betrachten wir die verschiedenen Software-Kategorien. In Komponenten der A-Kategorie konzentrieren wir fachliche Logik, die unabhängig von jeglicher Technik ist. In der T-Kategorie konzentrieren wir technisch motivierte Logik, die unabhängig von der fachlichen Logik ist, und in der sogenannten 0-Kategorie wird alles konzentriert, was unabhängig von Technik und Fachlichkeit ist.

Ein mögliches Ergebnis dieser Überlegungen ist ein 3-Tiers-System (Browser, Application-Server, Datenbank) mit einer View-Schicht, einer Business-Schicht und einer Persistenzschicht. Die neu gefundenen logisch motivierten Komponenten sollten jeweils mit Schnittstellen ausgestattet werden, die den Zugriff auf diese Komponenten oder auf andere Komponenten beschreiben. Mit Hilfe des Adapter- und des Fassaden-Entwurfsmuster ist es möglich, die Schnittstellen sehr übersichtlich zu gestalten.



Über die Schichten hinweg müssen in diesem Teil des Entwurfs auch eindeutige Zugriffsrichtungen festgelegt werden. So darf eine View-Komponente immer nur auf eine Business-Komponente zugreifen, niemals aber eine Business-Komponente auf eine View-Komponente.

Die logische Architektur zeigt einen Grobentwurf. Sie ist geeignet als Grundlage für die Kommunikation zwischen Projektleiter, Architekt oder Entwickler. In agilen Projekten wird sie genauso wie der Rest iterativ und inkrementell durchgeführt und dient der Kommunikation zwischen Product Owner und Projektteam.

In dem von mir mit Begeisterung gelesenen Buch "Softwarearchitekuren dokumentieren und kommunizieren" [ZÖR12] stehen die geeigneten Dokumentationsmethoden, um die Ideen zu Papier zu bringen. Besonders geeignet erscheint mir die beschriebene Bausteinsicht. Dabei werden die verschiedenen Komponenten als Bausteine in einem UML-Komponentendiagramm dargestellt. Die Schnittstellen werden mit Hilfe eines Klassendiagrammes modelliert.

Auch in unserer Praxis hat sich dabei immer die Dokumentation als Diagramm in Verbindung mit einer erklärenden Tabelle bewährt. Auf reinen Freitext greifen wir nur in der letzten Not zu. Ellenlange Texte ohne visuelle Darstellungen und übersichtlich geordnete Tabellen wirken ermüdend und haben den Effekt des Vergessens. Oft ist der lange Freitext ein Zeichen von Eile oder fehlendem Einfall für eine bessere Darstellung.



Methodenname Beschreibung
methode1() Macht folgendes ...
methode2() Macht jenes ...


Im letzten Teil dieser Reihe werden die logischen Komponenten zu technischen Komponenten. Für Enterprise-Architekturen haben wir dann den Bogen vom Requirements Enginnering zum Codieren geschlagen.

  • [REUS09] Ralf Reussner, Wilhelm Hasselbring: "Handbuch der Softwarearchitektur", 2. überarbeitete und erweiterte Auflage, dpunkt.verlag GmbH, Heidelberg, 2009
  • [BAU06] Ralf Baumann: "Entwurf und Implementierung eines webbasierten Vokabeltrainers mit Hilfe des Struts-Frameworks", Projektarbeit an der FH Trier,2006
  • [ZÖR12] Stefan Zörner: "Softwarearchitekturen dokumentieren und kommunizieren", Carl Hanser Verlag München, 2012


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen