 | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights | ||||||||||||||||||||||||||||||||||||||||||||
| Wissensbrowser starten | ||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||
| ||||||
|  | |  | |  | |
| ||||||
| ||||||
|  | | ||||
| ||||||
Arbeitsmaterialien |
|
Fachlogische Architektur |
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| Beschreibung der Komponente | |||||||||
| |||||||||
| Grundlage für die Modellierung der fachlogischen Architektur ist die Fachklassenmodellierung. Auf ihrer Grundlage werden die Datenklassen (Geschäftsklassen, Businessklassen, Geschäftsobjekte oder Businessobjekte) und die Software-Komponenten identifiziert und in UML-Diagrammen modelliert. Daten-Klassen und Software-Komponenten sind zwei verschiedene Sichten auf das System.
Modellierung der Daten Bei den Daten-Klassen geht es um die elementaren Träger von Informationen. Diese Daten-Klassen können untereinander relationale Beziehungen haben, wie z.B. ein Konto hat (steht in Beziehung mit) einen Kontoinhaber. Sie können auch Verallgemeinert bzw. Spezialisiert werden, wie z.B. Personen, Organisationen und Firmen sind Geschäftspartner. Modellierung der Komponenten-Architektur Eine vollständig andere Sicht auf das System ist die Zerlegung des gesamten Softwaresystems in fachlogische Komponenten. Komponenten sind Software-Bausteine, die bestimmte Aufgaben zu erfüllen haben. In der Regel gibt es Verwaltungs-Komponenten, die neben der Datenverwaltung von Daten-Klassen auch Suchfunktionen und komplexere Operationen über den Datenbeständen bereitstellen. Weitere Beispiele sind Komponenten, die komplexere Berechnungen durchführen oder den Im- bzw. Export von Daten zu anderen Systemen abwickeln. Daneben gibt es Steuerungskomponenten, die in der Regel komponentenübergreifende Abläufe steuern. Komponenten stehen untereinander in einer Benutzt- oder Aufruf-Beziehung, d.h. eine Komponente A benutzt eine Komponente B, ruft also mindestens eine Methode der Export-Schnittstelle von B auf. In der fachlogischen Komponenten-Architektur gibt es keine Vererbung zwischen den Komponenten, sondern alle Komponenten werden konkret mit ihren Aufgaben benannt. Beschreibung der Schnittstellen-Komponenten Nachdem die Komponenten-Architektur entworfen wurde und die Aufgaben der einzelnen Komponenten benannt wurden, werden die Schnittstellen möglichst genau beschrieben. Eine vollständige Beschreibung enthält die Import- und Export-Schnittstellen jeder Komponente, eine minimale Beschreibung die Export-Schnittstellen. In den Schnittstellen werden die Datenklassen (Geschäfts-Objekte) genannt und Methoden mit ihren formalen Parametern beschrieben. Modellierung von Aktivitätsdiagrammen Als nächstes werden die Anwendungsfälle konkretisiert, d.h. es werden Aktivitätsdiagramme erstellt. In der Regel wird ein Aktivitätsdiagramm durch ein Zeitereignis, ein Ereignis von einem anderen System oder von einem Ereignis aus der Oberfläche aktiviert. Bei einem Oberflächen-Ereignis erhält das Aktivitätsdiagramm Daten-Klassen von der Oberfläche, steuert die Reihenfolge der Methodenaufrufe von verschiedenen Komponenten, transportiert damit die Daten-Klassen von einer Komponente zur nächsten und übergibt meist eine Ergebnis-Datenklasse der Oberfläche. Ein Aktivitätsdiagramm beschreibt einen beispielhaften Ablauf und gehört zu einer (Steuerungs-)Komponente. Es wird also beispielhaft ein Stück Programm dieser Komponente beschrieben. Mit der Modellierung der Aktivitätsdiagramme überprüft man die Schnittstellen, ob sowohl die Aufgaben als auch die Argumente dafür ausreichend sind. Gleichzeitig verifiziert man die Komponentenaufteilung. Durch die Modellierung der fachlogischen Architektur wurden sehr genau die Anforderungen verifiziert, d.h. danach sind die Anforderungen mit hoher Wahrscheinlichkeit vollständig und widerspruchsfrei. Gleichzeitig hat man eine formale Beschreibung geschaffen, die Grundlage für die Software-Entwicklung ist. | |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
| |||||||||
Eintrag kommentieren | ||||
| ||||
 | Übergeordnet | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| ||||
| Fachlogische Architektur | ||||
| ||||
| ||||
| ||||
| ||||
| Ansprechpartner | | ||
| ||||
|
| | ||
| ||||
| ||||
| ||||
| Weitere Themen | | ||
| ||||
|
| | ||
| ||||
| ||||
| | | ||
| ||||||||||||||
|
