Konzept: Komponentenlösungen entwickeln
Die komponentenbasierte Entwicklung ist eine Unterart der Anwendungsentwicklung. In dieser Richtlinie werden mit dem Begriff "Komponente" unabhängig entwickelte und implementierbare Komponenten bezeichnet.
Hauptbeschreibung
Aktivitäten während des Lebenszyklus
  1. Einführung
  2. Aktivitäten während der Konzeptionsphase
  3. Aktivitäten während der Ausarbeitungsphase
  4. Aktivitäten während der Konstruktionsphase
  5. Aktivitäten während der Übergangsphase
Zusätzliche Themen:

Einführung

Die komponentenbasierte Entwicklung ist eine Unterart der Anwendungsentwicklung. Für sie gilt:

  • Die Anwendung wird aus einzelnen ausführbaren Funktionen erstellt, die relativ unabhängig voneinander entwickelt und implementiert wurden, eventuell sogar von verschiedenen Teams.
  • Die Anwendung kann in kleinen Schritten aufgerüstet werden, indem nur jeweils einige ihrer Bausteinkomponenten aufgerüstet werden.
  • Bausteinkomponenten können von mehreren Anwendungen gemeinsam genutzt werden; daraus ergeben sich einerseits eine gute Wiederverwendbarkeit, aber andererseits auch projektübergreifende Abhängigkeiten.
  • Obwohl sie nicht unbedingt auf Komponenten basieren müssen, sind komponentenbasierte Anwendungen normalerweise verteilt.

In diesem Dokument werden mit dem Begriff "Komponente" unabhängig entwickelte und implementierbare Komponenten bezeichnet. Ansonsten wird der Begriff "Komponenten" in RUP in einem allgemeineren Sinne verwendet und nach Bedarf qualifiziert, wie im Abschnitt Konzept: Komponente beschrieben.

Diese Anpassung von Rational Unified Process (RUP) für die Lösung der Probleme bei der komponentenbasierten Entwicklung wird nachfolgend erläutert.

Aktivitäten während der Konzeptionsphase

Der grundlegende Workflow für die Konzeptionsphase wird mit den folgenden Erweiterungen oder Varianten angewendet:

Projektmanagement

  • Aktivität: Neues Projekt konzipieren
  • Die Aufgabe: Kosten-Nutzen-Analyse entwickeln basiert auf der Annahme, dass die Verwendung von Komponenten die Kostenstruktur der Entwicklung ändert. Insbesondere nehmen die Kosten für die Entwicklung der Komponenten ab. Derer Aufwand für die Identifizierung von Komponenten nimmt jedoch zu. Außerdem wird auch mehr Zeit dafür aufgewendet, zu überprüfen, ob ausgewählte Komponenten mit Anforderungen übereinstimmen.

  • Aktivität: Projektumfang und Risiko bewerten
  • Der komponentenbasierte Ansatz ändert das Wesen bestimmter Risiken und führt neue Risiken ein. Insbesondere ist Folgendes zu beachten:

    • Komponenten mit externen Quellen erhöhen das Risiko, da sie kritische Elemente einführen, die nicht der direkten Kontrolle des Projektteams unterliegen.
    • Komponenten mit externer Quelle können Entwicklungszeit und Ressourcenrisiken reduzieren.
    • Komponenten mit externen Quellen können die Architektur des Systems verzerren, wenn sie selbst Einschränkungen für die Architektur mit sich bringen.
  • Aktivität: Projekt planen
  • In der Aufgabe: Phasen und Iterationen planen kann der Plan für die Konstruktionsphase zeigen, dass das Projekt sich in zwei verschiedene, jedoch parallele Wege aufteilt: einen für die Entwicklung der anwendungsspezifischen und domänenspezifischen Komponenten (angeordnet in den oberen Architekturschichten - siehe Konzept: Schichten) und einen für die Entwicklung der nicht anwendungsspezifischen und nicht domänenspezifischen Komponenten, die in den unteren Schichten angeordnet sind. In einigen Fällen werden wieder verwendbare Komponenten von unabhängig verwalteten Entwicklungsteams entwickelt. Die Entscheidung zur Einführung paralleler Verfahrenswege ist in erster Linie eine Personal- und Ressourcenfrage. Dies geschieht, um wieder verwendbare Komponenten als Assets zu verwalten, unabhängig von den Anwendungen, in denen sie implementiert werden.

Anforderungen

  • Aktivität: Systemdefinition präzisieren
  • Wenn Sie die Systemanforderungen präzisieren, müssen die vom ausgewählten Komponentengerüst vorgegebenen Einschränkungen erfasst werden. Komponentengerüste verbessern die Produktivität bei der Entwicklung teilweise, indem sie die Freiheiten bei der Softwarearchitektur und dem Design einschränken. Die Aufgabe: Softwareanforderungen ausführlich beschreiben muss sich darauf konzentrieren, diese Einschränkungen zu dokumentieren.

Test

Umgebung

  • Aktivität: Umgebung für Projekt vorbereiten
  • Wenn Sie Richtlinien für das Projekt erfassen und vorbereiten möchten, finden Sie detaillierte Informationen unter  Aufgabe: Richtlinien für das Projekt vorbereiten. Berücksichtigen Sie das spezifische Komponentengerüst mit seinen Vorgaben. Die Richtlinien sollten beschreiben, wie das Design und die Codierung mit dem Gerüst funktionieren. Sie sollten auch eine Testanleitung beinhalten, mit der die Konformität mit dem Komponentengerüst selbst und mit den zwischen den Komponenten definierten Schnittstellen geprüft werden kann.

Aktivitäten während der Ausarbeitungsphase

Der grundlegende Workflow für die Ausarbeitungsphase ist mit den folgenden Erweiterungen oder Varianten gültig:

Anforderungen

  • Aktivität: Systemdefinition präzisieren
  • Die Aufgabe: Softwareanforderungen ausführlich beschreiben konzentriert sich darüber hinaus auf die technischen und nicht funktionalen Voraussetzungen und Einschränkungen für die erstellten oder gekauften Komponenten. Spezifische, nicht funktionale Voraussetzungen, die zu berücksichtigen sind, sind Größe, Leistung, Speicher- oder Plattenkapazität, Fragen der Laufzeitlizenz und ähnliche Einschränkungen, die die Komponentenauswahl oder -erstellung beeinflussen.

Analyse und Design

  • Aktivität: Komponenten entwerfen
  • Die Aufgabe: Subsystemdesign verfeinert das Design der Komponenten weiter, indem sie in der Komponente Klassen angibt, die das reale Verhalten der Komponente bestimmen. Früh in der Ausarbeitungsphase gibt es eine einzelne Klasse, eine Art 'Subsystem-/Komponenten-Proxy', die als Stub fungiert, um das Verhalten der Komponente für die Erstellung von Architekturprototypen zu simulieren. Zu einem späteren Zeitpunkt wird das Verhalten dieser Klasse im Kontext einer Zusammenarbeit von Klassen innerhalb des Subsystems verteilt. Diese enthaltenen Klassen werden in der Aufgabe: Klassendesign präzisiert.

  • Aktivität: Datenbank entwerfen
  • Der Schwerpunkt bei der Ausarbeitung liegt darin, sicherzustellen, dass die Persistenzstrategie skalierbar ist und dass das Datenbankdesign und der Persistenzmechanismus die Durchsatzanforderungen des Systems unterstützen. Persistente Klassen werden identifiziert und dem Persistenzmechanismus zugeordnet. Datenintensive Anwendungsfälle werden analysiert, um die Skalierbarkeit der Mechanismen sicherzustellen. Der Persistenzmechanismus und das Datenbankdesign wird in Verbindung mit den Testaktivitäten bewertet und überprüft.

Implementierung

Test

  • Aktivitäten: Bewertungsauftrag definieren, Testansatz überpüfen, Testen und bewerten, Auftrag "Annehmbarkeit der Testergebnisse prüfen" Test-Assets verbessern

    Die Testaktivitäten in der Ausarbeitungsphase konzentrieren sich auf die Überprüfung der Architektur. Für ein komponentenbasiertes System bedeutet das Folgendes:

    • Die Schnittstellen zwischen Komponenten ausführen, um sicherzustellen, dass Grenzwerte für Komponenten entsprechend gesetzt wurden.
    • Ein erhöhtes Gewicht auf Leistungstests legen, insbesondere Tests zur Leistungsskalierung, um sicherzustellen, dass vorgesehene Transaktionsvolumina ausgeführt werden können.

    Alle Annahmen im Komponentengerüst müssen ebenfalls bewertet werden. Diese Annahmen beziehen sich meist auf die Skalierbarkeit und den Durchsatz des Persistenzmechanismus und des Mechanismus für die Transaktionsverwaltung, in denen verdeckte Annahmen des Designers der Mechanismen die Anwendungsarchitektur oft vollkommen unterhöhlen.

Projektmanagement

  • Aktivität: Plan für nächste Iteration

    Wenn die Implementierungssubsysteme als logische Einheiten der Zuständigkeiten verwendet werden, kann die Konstruktionsarbeit in ein oder mehrere Verfahrenswege aufgeteilt werden: einen, der sich auf die anwendungsspezifische Funktionalität konzentriert und einen, der sich auf generische, wieder verwendbare Komponenten konzentriert. Dabei wird vorausgesetzt, dass ausreichende Personalressourcen für parallele Entwicklungsaktivitäten vorhanden sind. Die Fähigkeit, die Entwicklungsteams aufzuteilen und parallel zu arbeiten, hängt völlig von der Stabilität der Architektur und insbesondere von der Qualität und Stabilität der Schnittstellen zwischen den Komponenten ab. Diese Unterteilung kann durch einen höheren Aufwand in der Konstruktionsphase bewerkstelligt werden.

Aktivitäten während der Konstruktionsphase

Der grundlegende Workflow für die Konstruktionsphase wird mit den folgenden Erweiterungen oder Varianten angewendet:

Projektmanagement

  • Aktivität: Plan für nächste Iteration

    Die Planung für die erste Konstruktionsiteration, so wie sie gegen Ende der Ausarbeitung erfolgt, wurde zuvor beschrieben. Die nachfolgende Iterationsplanung und die Fähigkeit, die Entwicklungsteams aufzuteilen und parallel zu arbeiten, hängt weiter völlig von der Stabilität der Architektur sowie der Qualität und Stabilität der Schnittstellen zwischen den Komponenten ab.

Analyse und Design

  • Aktivität: Architektur präzisieren und Aktivität: Komponenten entwerfen

    In der Konstruktionsphase liegt der Schwerpunkt darauf, die verbleibenden Anwendungsfälle zu analysieren und passende Komponenten und Komponentenkollaborationen, die die Anwendungsfälle realisieren können, zu identifizieren. Die vorhandene Architektur wird erweitert und abgeschlossen, und das interne Verhalten der Komponente wird vollständig entworfen und implementiert.

  • Aktivität: Datenbank entwerfen

    In der Konstruktionsphase liegt der Schwerpunkt darauf, das Datenbankdesign zu vervollständigen. Dabei soll sichergestellt werden, dass alle persistenten Klassen von der Datenbank und dem Persistenzmechanismus unterstützt werden. Diese Arbeitsvorgänge werden iterativ und parallel zu den unter Aktivität: Architektur präzisieren und Aktivität: Komponenten entwerfen ausgeführten Arbeitsvorgängen ausgeführt. Idealerweise hat eine Organisation integrierte Komponententeams mit teamübergreifender Koordination von Persistenzfragen, um ein gutes Datenbankdesign sicherzustellen.

Implementierung

Test

Die Leistungstests bleiben wichtig, der Schwerpunkt verlagert sich jedoch auf die Funktionstests. Die Vollständigkeit der Funktionalität, der Regressionstest vorhandener Funktionalität sowie die Übereinstimmung mit Leistungserwartungen - all dies muss berücksichtigt werden.

Aktivitäten während der Übergangsphase

  • Das Produkt-Release in der Webumgebung wird fortlaufend und inkrementell durchgeführt und ist weniger auf die traditionelle Verteilung der Daten ausgerichtet. Die Release-Planung muss entsprechend angepasst werden.
  • Die Produktunterstützung rückt in dieser Phase immer mehr in den Mittelpunkt.
  • Es werden Datenkonvertierungen ausgeführt.