Tipps und Tricks mit UML - JAXenter

Tipps und Tricks mit UML

Wie stelle ich die Schnittstellen in der UML dar?

Die UML bietet unterschiedliche Darstellungsmöglichkeiten für Schnittstellen. Eine Möglichkeit ist die Darstellung durch Interfaceklassen. Hier legen Sie eine Klasse mit dem Stereotyp <<interface>> an. Die Komponente, welche dieses Interface zur Verfügung stellt, verbinden Sie anschließend über eine <<realize>>-Beziehung, die verwendende Komponente über eine <<use>>-Beziehung mit dieser Klasse. Eine abkürzende Schreibweise ist die „Ball & Socket“-Notation. Hier werden die angebotene Schnittstelle über eine Kugel (den so genannten Lollipop) und die benötigte Schnittstelle über einen Halbkreis dargestellt.

Das bereits erwähnte Delegieren von Schnittstellen wird in der UML-Notation durch einen Delegations-Konnektor dargestellt.

Da wir in der Systemarchitektur ja nicht nur reine Software betrachten, ist es oft wichtig, zwischen verschiedenen Arten von Schnittstellen zu unterscheiden. Mögliche Arten sind: die logischen Schnittstellen, die physikalischen (evtl. noch unterteilt in mechanische und elektronische) Schnittstellen und die Testschnittstellen.

Auch hier lässt sich das bereits bekannten Prinzip der Stereotypisierung anwenden. So haben Sie die Möglichkeit, Schnittstellen über die möglichen Stereotypen <<logical interface>>, <<physical interface>> und <<test interface>> näher zu definieren.

Zusammenfassung und Ausblick

In diesem Artikel haben wir Ihnen vorgestellt, welche Möglichkeiten uns die UML für die Darstellung einer Systemarchitektur bietet. Dabei sind wir einerseits auf die drei Haupttätigkeiten in dieser Entwicklungsphase eingegangen und haben typische Vorgehensweisen und Methoden angesprochen. Auf der anderen Seite haben wir gesehen, wie die UML als Notation bei diesem Prozess eingesetzt werden kann. Ein zentraler Bestandteil ist dabei der Einsatz der Stereotypisierung, sowohl im Bereich der Komponentenbildung als auch im Bereich der Schnittstellenklassifizierung. Sie haben gesehen, dass Analysetechniken wie die Use-Case-Analyse in der Systemarchitektur für eine nähere Untersuchung der Systemkomponenten eingesetzt werden können. In einem unserer nächsten Artikel werden wir auf die Verwendung der kürzlich verabschiedeten SysML zur Modellierung der Systemarchitektur eingehen.

Bleibt noch die Frage, wie geht es in Ihrem Projekt nun weiter? Während die gefundenen Hardwarekomponenten relativ losgelöst voneinander entwickelt werden können, kommt den Softwarekomponenten eine Sonderrolle zu. Diese werden nun in den meisten Fällen wieder in einen Topf geworfen und einer expliziten Software-Analyse unterzogen. Die Idee liegt nahe, dass gewisse Aufgaben der Softwarekomponenten sich wiederholen und somit eine getrennte Entwicklung nach Systemkomponenten eine unnötige Mehrarbeit bedeuten würde. Natürlich vorausgesetzt, dass die Software nicht ebenfalls durch den externen Zulieferer der Komponenten realisiert wird. Anschließend wird dann zu entwickelnde Software in der Software-Architektur logisch zerlegt und danach zu den aus der Systemarchitektur geforderten Teilen zusammengesetzt.

Dr. Stefan Queins setzt als Berater objektorientierte Methoden und Notationen in den Bereichen der Systemanalyse und Architektur von technisch orientierten Systemen ein. Daneben coacht er die Einführung angepasster Vorgehensmodelle in Entwicklungsprojekten. Auch im Trainingsbereich vermittelt er in den genannten Bereichen sein Wissen. Stefan ist Mitarbeiter der SOPHIST GROUP und Co-Autor von „UML 2 glasklar“. Kontakt: Stefan.Queins[at]SOPHIST.de.

Anja Ranft wechselte nach ihrem Studium der Informatik an der TU München zu den SOPHISTen, wo sie als Beraterin in den Bereichen Systemanalyse und Systemarchitektur ihr Wissen an den Mann (und die Frau) bringt. Während ihres Studiums konnte sie auch im Bereich Projektmanagement erste Erfahrungen sammeln. Kontakt: Anja.Ranft[at]SOPHIST.de.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.