Benutzerspezifische Werkzeuge

Komponentenorientierter Softwareentwurf

Beim komponentenorientierten Softwareentwurf werden Softwarekomponenten zur Strukturierung von Softwaresystemen verwendet. Wesentliche Teilaufgaben stellen dabei insbesondere die Identifikation und Spezifikation von Softwarekomponenten sowie deren Verknüpfung zum Softwaresystem dar.

Definition

Der komponentenorientierte Softwareentwurf stellt eine in Bezug auf das zur Strukturierung eingesetzte Paradigma spezielle Form des Softwareentwurfs dar, bei der ein Softwaresystem in Softwarekomponenten zerlegt wird. Der komponentenorientierte Softwareentwurf umfasst die Definition der Softwarearchitektur, Softwarekomponenten und Programmierschnittstellen sowie die Vereinbarung weiterer im Rahmen der Entwicklung einzuhaltender Merkmale [Cheesman und Daniels 2001, S. 25ff.].

Zu den wesentlichen Teilaufgaben des komponentenorientierten Softwareentwurfs gehören

  • die Identifikation der Softwarekomponenten des zu entwickelnden Softwaresystems,
  • die Einbeziehung wiederverwendbarer Softwarekomponenten,
  • die Beschreibung der Außensicht der identifizierten Softwarekomponenten sowie
  • die Verknüpfung der Softwarekomponenten zum Softwaresystem.

Das Ergebnis des Entwurfsprozesses ist ein vollständiger Plan des Softwaresystems mit Vorgaben, die die Beschaffung wiederzuverwendender Softwarekomponenten, die Entwicklung noch nicht vorhandener Softwarekomponenten und deren spätere Konfiguration ermöglichen.

Neu zu entwickelnde Softwarekomponenten sind anschließend im Rahmen des Komponentenentwurfs zu entwerfen. Aufsetzend auf den o.g. Vorgaben wird dabei die Innensicht mit konkreten Angaben zur Implementierung festgelegt.

Strukturierungsparadigma

Bei einem komponentenorientierten Softwareentwurf sind Softwaresysteme in möglichst unabhängig zu wartende, wiederverwendbare Softwarekomponenten zu zerlegen. Dieses Ziel lässt sich erreichen, indem bei der Definition von Softwarekomponenten dem Entwurfsprinzip der maximalen Kohäsion bei gleichzeitig minimalen Abhängigkeiten gefolgt wird [Szyperski et al. 2002, S. 40; Parnas 1972]. Zwischen Softwarekomponenten sollen danach nur möglichst wenige Aufrufe erfolgen, um eine möglichst hohe Unabhängigkeit zu gewährleisten. Um zugleich die Abgeschlossenheit und Wiederverwendbarkeit sicherzustellen, sind in einer Softwarekomponente nur Systemteile zusammenzufassen, zwischen denen möglichst viele Aufrufe erfolgen. Die Granularität der einzelnen Softwarekomponenten kann dabei flexibel schwanken um das beschriebene Entwurfsprinzip optimal zu erfüllen [Szyperski et al. 2002, S. 45]. Die Erfüllung des o.g. Entwurfsprinzips lässt sich als Optimierungsproblem formulieren und mit Methoden des Operations Research (näherungsweise) lösen [Albani et al. 2008].

Methoden und Werkzeuge

Der komponentenorientierte Softwareentwurf wird durch eine Vielzahl von Methoden und Werkzeugen unterstützt. Insbesondere existieren zahlreiche Ansätze, die sich bei der Identifikation von Komponenten einsetzen lassen. Ein Überblick über Ansätze zur Identifikation von Komponenten, die von sog. Best Practices über allgemeine Entwurfsrichtlinien bis hin zu optimierenden Verfahren reichen, findet sich bei [Birkmeier und Overhage 2009].

UML Kompositionsstrukturdiagramm (Beispiel)

Abb. 1: Kompositionsstrukturdiagramm zur Dokumentation eines komponentenorientierten Softwareentwurfs für ein Bibliothekssystem (vereinfacht)

Zur Modellierung der Softwarearchitektur lassen sich bspw. Kompositionsstrukturdiagramme verwenden, die Bestandteil der UML sind (siehe Abbildung 1). Diese unterstützen auch die Definition sog. Angebots- und Nachfrageschnittstellen, mit denen sich die Programmierschnittstellen von Softwarekomponenten beschreiben lassen. Sie stellen damit zugleich den Ausgangspunkt für die Beschreibung der Außensicht von Softwarekomponenten dar. Weitere Hinweise zur Beschreibung der Außensicht von Softwarekomponenten finden sich bei [Overhage2004].

Darüber hinaus gibt es Ansätze, mit denen sich Qualitätsmerkmale eines Softwaresystems auf Basis der Qualitätsmerkmale seiner Softwarekomponenten und der Softwarearchitektur vorhersagen lassen [Grunske 2007]. Ein komponentenorientierter Softwareentwurf lässt sich damit bereits frühzeitig auf die Einhaltung bestehender Qualitätsanforderungen hin überprüfen.

Literatur

Albani, Antonia; Overhage, Sven; Birkmeier, Dominik: Towards a Systematic Method for Identifying Business Components. In: Chaudron, Michel R. V.; Szyperski, Clemens; Reussner, Ralf (Hrsg.): Component-Based Software Engineering – Proceedings of the 11th International Symposium CBSE 2008. Lecture Notes in Computer Science Nr. 5282. Springer: Heidelberg 2008, S.262-277.

Birkmeier, Dominik; Overhage, Sven: On Component Identification Approaches – Classification, State of the Art, and Comparison. In: Lewis, Grace A.; Poernomo, Iman; Hofmeister, Christine (Hrsg.): Component-Based Software Engineering – Proceedings of the 12th International Symposium CBSE 2009. Lecture Notes in Computer Science Nr. 5582. Springer: Heidelberg 2009, S.1-18.

Cheesman, John; Daniels, John: UML Components – A Simple Process for Specifying Component-Based Software. Addison-Wesley: Upper Saddle River 2001.

Grunske, Lars: Early quality prediction of component-based systems - A generic framework. In: Journal of Systems and Software 80 (2007) 5, S. 678-686.

Overhage, Sven: UnSCom: A Standardized Framework for the Specification of Software Components. In: Weske, Mathias; Liggesmeyer, Peter (Hrsg.): Object-Oriented and Internet-Based Technologies – Proceedings of the Net.ObjectDays 2004. Lecture Notes in Computer Science Nr. 3263. Springer: Heidelberg 2004, S.169-184.

Parnas, David L.: On the Criteria to be Used in Decomposing Systems into Modules. In: Communications of the ACM 15 (1972) 12, S. 1053-1058.

Szyperski, Clemens; Gruntz, Dominik; Murer, Stephan: Component Software – Beyond Object-Oriented Programming. Addison-Wesley: Harlow 2002.

 

Einordnung: ,
Letzter Abruf: 24.05.2012 22:34
Artikelaktionen