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 dem ein Softwaresystem in Softwarekomponenten zerlegt wird. Der komponentenorientierte Softwareentwurf umfasst die Definition der Softwarearchitektur, die Definition der Softwarekomponenten und ihrer 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 wartbare und wiederverwendbare Softwarekomponenten zu zerlegen. Diese Ziele lassen sich verfolgen, 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 einerseits möglichst wenige Aufrufe erfolgen, um eine möglichst hohe Unabhängigkeit zu gewährleisten. Um die Wiederverwendbarkeit einer Softwarekomponente in verschiedenen Anwendungsszenarien sicherzustellen, sollen in einer Softwarekomponente andererseits nur Systemteile mit einem möglichst hohen Grad an Zusammengehörigkeit zusammengefasst werden. Ein hoher Grad an Zusammengehörigkeit zwischen Systemteilen wird unterstellt, wenn zwischen diesen 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 bspw. mit Methoden des Operations Research oder des Soft Computing (näherungsweise) lösen [Birkmeier und Overhage 2013].
Methoden und Werkzeuge
Der komponentenorientierte Softwareentwurf wird durch eine Vielzahl von Methoden und Werkzeugen unterstützt. Es existieren zahlreiche unterschiedliche 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; Birkmeier und Overhage 2013].
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 [Szyperski et al. 2002; 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 [Becker et al. 2009; Burger und Reussner 2011]. Ein komponentenorientierter Softwareentwurf lässt sich damit bereits frühzeitig auf die Einhaltung bestehender Qualitätsanforderungen hin überprüfen.
Literatur
Becker, Steffen; Koziolek, Heiko; Reussner, Ralf: The Palladio component model for model-driven performance prediction. In: Journal of Systems and Software 82 (2009) 1, S. 3-22.
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.
Birkmeier, Dominik; Overhage, Sven: A Method to Support a Reflective Derivationr of Business Components from Conceptual Models. In: Information Systemsand e-Business Management 11 (2013) 3, S. 403-435.
Burger, Erik; Reussner, Ralf: Performance Certification of Software Components. In: Electronic Notes in Theoretical Computer Science 279 (2011) 2, S. 33-41.
Cheesman, John; Daniels, John: UML Components – A Simple Process for Specifying Component-Based Software. Addison-Wesley: Upper Saddle River 2001.
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
