Model Driven Requirements Engineering

Transkript

1 1 Model Driven Requirements Engineering Mattanja Kern Hauptseminar Requirements Engineering 01. Februar 2008 Institut für Softwaretechnologie (ISTE), Universität Stuttgart, Deutschland Zusammenfassung In den letzten Jahren ist das Interesse am Model Driven Engineering (MDE) stetig gewachsen. Durch MDE werden Softwarearchitekten und -programmierer in ihrer Arbeit unterstützt, indem automatisch Teile der Software aus den Modellen generiert werden. Auf die Anforderungserfassung hatte diese Entwicklung jedoch bisher geringen Einfluss. Die Spezifikation von Softwaresystemen erfolgt in vielen Fällen mit Textverarbeitungssoftware oder mit spezialisierter Software zum Requirements Engineering und zum Requirements Tracking, ohne dabei das Model Driven Engineering zu beachten. Diese Arbeit beschäftigt sich mit den Möglichkeiten, die sich durch die Nutzung der MDE-Techniken im Requirements Engineering bieten. Neben der Betrachtung zweier Ansätze der Forschung, werden erste Produkte in diesem Zusammenhang betrachtet, sowie einige Vor- und Nachteile der Nutzung von MDE bei der Anforderungserfassung hervorgehoben. 1 EINLEITUNG IN DEN letzten Jahren hat das Model Driven Engineering zunehmend an Bedeutung gewonnen. Diese Entwicklung kann nicht ohne Einfluss auf die Anforderungserfassung und -spezifikation bleiben. Diese Seminararbeit beschäftigt sich mit den Möglichkeiten, die durch die Nutzung des Model Driven Engineering bereits in der Phase der Anforderungserfassung entstehen, sowie mit den Problemen die dies mit sich bringen kann. Zunächst bietet Kapitel 2 eine kurze Einführung in das Model Driven Engineering, insbesondere in den Standard Model Driven Architecture mit UML. Die modellgetriebene Anforderungserfassung wird im Abschnitt 2.2 erklärt. Anschließend werden in Kapitel 3 zwei Verfahren vorgestellt, die es ermöglichen sollen, mit der modellgetriebenen Softwareentwicklung unmittelbar an die Spezifikation anzuschließen, und die Phasen der Spezifikation und der Softwarearchitektur miteinander zu verknüpfen. In Kapitel 4 schließlich findet sich ein Überblick über Softwareprodukte zur Unterstützung des Model Driven Requirements Engineering. Abschließend werden in Kapitel 5 die Möglichkeiten und Probleme beleuchtet, die sich durch das Model Driven Requirements Engineering ergeben. 2 MODEL DRIVEN ENGINEERING Model Driven Engineering (MDE) bezeichnet eine Vorgehensweise bei der Entwicklung eines Softwaresystems, bei der das System durchgängig mit Hilfe von Modellen beschrieben wird. Der Industriestandard und die bekannteste Umsetzung, Model Driven Architecture, wird in Kapitel 2.1 beschrieben. Ziele des Model Driven Engineering sind, die Entwicklung von Software zu beschleunigen und die Qualität der Software zu erhöhen [1]. Erreicht werden sollen diese Ziele dadurch, dass Softwarearchitekten durch Modelle, unterstützt werden, die das Verständnis des Systems verbessern sollen. Ein großer Teil dieser Modelle ist grafisch und bietet damit dem Architekt visuelle Unterstützung bei der Planung z.b. des Zusammenspiels der Softwarekomponenten. Die Trennung des Modells von der Zielplattform spielt eine wichtige Rolle im Model Driven Engineering. Das Computation Independent Model (CIM) ist unabhängig vom formalen Modell und beschreibt das System auf fachlicher Ebene. Die Funktionalität des Systems wird unabhängig von der Zielplattform im sogenannten Platform Independent Model (PIM) beschrieben. Mit Hilfe von Plattforminformationen wird dieses anschließend in das Platform Specific Model (PSM) transformiert. Das PSM nutzt dann bestimmte Eigenschaften der Plattform aus, wie z.b. Programmierschnittstellen des Betriebssystems. Die Trennung dieser Modelle spielt jedoch in diesem Zusammenhang keine große Rolle und wird deshalb nicht weiter betrachtet. Eine wichtige Rolle spielen jedoch automatische Transformationen der Modelle in Code, bzw. in die nächste Modellebene. Der Grundgedanke ist es, Modelle durch die Auswahl von Plattformen in weniger abstrakte Modelle zu transformieren, bis letztendlich ausführbarer Programmcode entsteht. So werden zum Beispiel aus Klassendiagrammen Code-Rümpfe generiert, oder aus umfassenderen Modellen wird ein ausführbares Programm erzeugt. Ziel ist dabei nicht zwingend ein vollständiges Modell auf der nächsten Ebene, sondern ein Modell das weiter verfeinert werden kann, bevor der nächste Transforma-

2 2 tionsschritt erfolgt. 2.1 Model Driven Architecture Model Driven Architecture (MDA) ist ein Markenzeichen der Object Management Group und ist deren Bezeichnung für die Umsetzung des Model Driven Engineering. Der wichtigste Bestandteil der MDA ist die Spezifikation der Modellierungssprache Unified Modeling Language (UML), sowie die übergeordnete Meta- Modellierungssprache Meta Object Facility (MOF). Eine weitere Sprache ist die Object Constraint Language (OCL) zur Definition von Regeln in UML-Modellen. Diese spielt eine wichtige Rolle bei der Automation der Transformationen. Mit Hilfe diese Sprache werden Zusammenhänge und Beschränkungen der modellierten Elementen ausgedrückt. Mit der Meta-Modellierungssprache MOF können die Meta-Modelle ergänzt werden. So kann zum Beispiel ein Entwicklungswerkzeug ein eigenes UML-Profil definieren, um ein spezielles Teilgebiet besser beschreiben zu können. Dieses UML-Profil kann anschließend mit Hilfe der XML-basierten Sprache XML Metadata Interchange (XMI) exportiert, und in anderen Werkzeugen importiert werden. Aktuell befindet sich mit SysML ein weiterer Sprachstandard der OMG im Validierungsprozess, mit dem Systeme umfassender als mit UML zu beschreiben sein sollen. SysML nutzt Teile der UML-Spezifikation und ergänzt diese um neue Diagrammtypen und Metamodelle. Dazu gehören insbesondere auch Elemente zur Modellierung von Anforderungen, mit der Möglichkeit diese untereinander, sowie mit Use-Cases zu verknüpfen. 2.2 Model Driven Requirements Engineering Bei der Softwareentwicklung spielt die Erfassung von Anforderungen eine wichtige Rolle. Anforderungen enthalten den eigentlichen Zweck einer Software, möglichst unabhängig von der Lösung, da diese häufig Einschränkungen mit sich bringt oder vom ursprünglichen Ziel abweichen kann [2]. Im Zusammenhang mit MDA findet die Anforderungsanalyse und -spezifikation bisher trotzdem geringe Beachtung. Ein Grund dafür könnte darin liegen, dass die Grenze zwischen der Spezifikation und der konkreten Lösung beim Einsatz der Model Driven Architecture teilweise verschwimmen. Das bedeutet, dass bei Verwendung von Modellen in der Anforderungserfassung zumindest ein Stück weit bereits in Lösungen gedacht wird. Ein weiterer Grund ist sicherlich die unzureichende Werkzeugunterstützung. Wie in Kapitel 4 gezeigt, existieren nur wenige Werkzeuge mit denen Model Driven Requirements Engineering (MDRE) betrieben werden kann. Das Computation Independent Model der MDA ist das am wenigsten formal vorgegebene Modell der MDA. Insofern kann eine durch freien Text definierte Spezifikation als CIM angesehen werden. Angereichert werden kann diese Spezifikation durch Anwendungsfalldiagramme, Interaktionsdiagramme und Aktivitätsdiagramme Verknüpfung zum Entwurf: Insbesondere bei sich verändernden Anforderungen ist eine klare Zuordnung der Anforderung auf die Realisierung hilfreich. Andernfalls kann es leicht vorkommen, dass die Entwicklung von der ursprünglichen Aufgabe der Software abweicht. Ein Ziel des Model Driven Requirements Engineering ist deshalb, die Zuordnung der Anforderung auf die spätere Umsetzung zu erleichteren. Ebenso soll die umgekehrte Zuordnung, also die Zuordnung des Lösungsteils zur Anforderung ermöglicht werden. Ein weiteres Ziel des MDRE ist es, Teile des Systementwurfs aus den Spezifikationsdokumenten zu gewinnen, um dadurch eine bessere Konsistenz und Verknüpfungen zwischen diesen Dokumenten zu erhalten, und den Arbeitsaufwand zu reduzieren. Die folgenden Arbeiten beschäftigen sich insbesondere mit dieser Idee der semiautomatischen Umwandlung von Teilen der Spezifikation in Modelle des Entwurfs. 3 WISSENSCHAFTLICHE ARBEITEN 3.1 Generierung von Sequenzdiagrammen aus Use- Case-Beschreibungen Die Autoren Díaz, Pastor und Matteo beschreiben in ihrer Publikation Modeling Interactions using Role- Driven Patterns einen Ansatz, mit dessen Hilfe UML- Sequenzdiagramme aus textuellen Use-Case Beschreibungen gewonnen werden sollen. Dies geschieht dabei durch die Anwendung wohlbekannter Muster auf die Rollen, die einzelne Elemente in den Use-Cases spielen. Ein Ziel dieses Ansatzes ist es, die Qualität der Software durch die Wiederverwendung bewährter Muster zu erhöhen. Ausgehend von der textuellen Use-Case Beschreibung wird mit Hilfe des von den Autoren beschriebenen Verfahrens, ein linguistisches Modell erzeugt. Diesem Modell liegt ein Meta-Modell zugrunde, das durch ein UML-Profil definiert wird. Eine genaue Beschreibung des Profils und des Algorithmus ist in [3] nachzulesen Rollen-basiert Ein zentraler Punkt in dem beschriebenen Verfahren ist die Abgrenzung des Textes gegen die angewandten Muster durch sogenannte Semantische Rollen. Durch diese Abstraktion der sprachlichen Beschreibung, können die Muster unabhängig vom Fachgebiet der Software angewandt werden. Eine Rolle beschreibt die Funktion, die ein Element innerhalb einer Interaktion spielt. Die semantischen Rollen des Subjekts (Akteur) und des direkten Objekts (Objekt) werden als Basisrollen bezeichnet, da sie in jedem Fall vorhanden sind. Diese Basisrollen können mit sekundären Rollen verknüpft werden. Sekundäre Rollen können zum Beispiel sein: Ziel (Empfänger einer Aktion), Besitzer (Besitzt andere

3 3 Instanz), Werkzeug (um eine Aktion durchzuführen) oder auch Zeitpunkt (zu dem die Aktion ausgelöst wird). Zum Beispiel enthielte der Satz Der Kunde gibt die Daten in das System ein das Subjekt Der Kunde mit der Rolle Akteur. Das direkte Objekt entspricht in diesem Beispiel dem Teil die Daten und das System wäre das Ziel Erzeugung der Sequenzdiagramme Die gewonnenen Verknüpfungen der semantischen Rollen werden im nächsten Schritt mit vordefinierten Mustern verglichen. Diese Muster enthalten das passende Sequenzdiagramm zur Interaktion der Rollen. Im oben genannten Beispiel müsste das in Abbildung 1 dargestellte rollenbasierte Modell bereits vordefiniert sein. Auf dieses Modell werden nun die Rollen Akteur, Objekt und Ziel angewandt, woraus das konkrete Modell wie in Abbildung 2 erzeugt wird. Abbildung 1. Rollenbasiertes Modell Abbildung 2. Konkretes Modell Bewertung Die Idee, auch sprachliche Modelle zur automatischen Transformation zu nutzen, hört sich zunächst einmal sehr interessant an. Die Autoren geben in ihrer Arbeit eine Quote der mit der Arbeit eines menschlichen Spezialisten übereinstimmenden Sequenzdiagramme von 93% an. Selbst wenn man davon ausgeht, dass dieser menschliche Spezialist fehlerfrei arbeitet ist es diese Zahl, die eine große Gefahr der Technik birgt: Entspricht die genannte Erfolgsquote von 93% der Realität, stellt sich die Frage, was im Falle der übrig bleibenden 7% Fehlern passiert. Naturgemäß können diese nur von einer erfahrenen Person erkannt werden. Die große Gefahr dabei ist, dass möglicherweise auf diese Art ein Interaktionsdiagramm erstellt, und damit eine Entwurfsentscheidung getroffen wird, die nicht der benötigten Anforderung entspricht und unter Umständen vollkommen fehlerhaft ist. Eine solche Entscheidung kann mit Sicherheit im weiteren Projektverlauf zu großen Problemen führen. Durch die Menge der erzeugten Diagramme, wird es für einen menschlichen Softwarearchitekten schwierig sein, eben genau die fehlerhaften Diagramme zu identifizieren. Auch ist der Nutzen der erzeugten Sequenzdiagramme fraglich. Ob die Diagramme neue Erkenntnis für den Betrachter bieten, bleibt in der Arbeit ohne genauere Betrachtung. Die erzeugten Diagramme sind mit Sicherheit in vielen Fällen so einfach, dass sie genausogut weggelassen werden könnten. Gut geeignet könnten die Sequenzdiagramme jedoch zur Identifikation einzelner interner Systemkomponenten sein. Mit den erzeugten Sequenzdiagrammen liegt ein erstes Modell der systeminternen Komponenten vor, das andernfalls aus dem Text erarbeitet werden müsste. Dieses Modell ist zudem so weit formalisiert, dass es auch automatisiert weiterverwendet werden kann. 3.2 Generierung von Zustandsdiagrammen aus Sequenzdiagrammen In dem von Jon Whittle und Johann Schumann vorgestellten Verfahren zur Generierung von Zustandsdiagrammen aus Sequenzdiagrammen [4] geht es ebenfalls darum, den Schritt von der Anforderungsspezifikation hin zum Entwurfsdokument zum Teil zu automatisieren und Schwächen in Sequenzdiagrammen feststellen zu können. Die Autoren sind Mitglieder der Robust Software Engineering Group bei Ames Research der NASA, was darauf schließen lässt, dass es ein wichtiges Ziel dieser Arbeit ist, die Qualität der Software zu verbessern. Dies könnte durch das darin beschriebene Vorgehen erreicht werden. Ziel dieses Ansatzes ist es nicht, vollständige, automatisch ausführbare Zustandsdiagramme zu gewinnen, sondern die Vollständigkeit und Korrektheit des Modells in der Spezifikation zu überprüfen, sowie die Verbindung zum Entwurf herzustellen. Ausserdem soll damit der Softwarearchitekt beim Entwurf durch die grafische Darstellung des Zustandsdiagrammes unterstützt werden und dieses weiter bearbeiten können. Deshalb ist die Lesbarkeit des erzeugten Diagramms eine wichtige Anforderung.

4 Umwandlung der einzelnen Sequenzdiagramme in Zustandsdiagramme Im ersten Schritt des vorgestellten Verfahrens wird jedes Sequenzdiagramm in ein Zustandsdiagramm, bzw. in einen endlichen Automaten umgewandelt. Dabei können Widersprüche oder Mehrdeutigkeiten auftreten, die auf ein unvollständiges oder fehlerhaftes hinterlegtes Fachwissen schließen lassen. Dieses Fachwissen (domain theory) wird benötigt, um Konflikte zu beheben und zu erkennen Fachwissen: Sequenzdiagramme enthalten nur sehr wenig semantische Information. Zur Umwandlung in Zustandsdiagramme sind deshalb weitere Angaben nötig. Die Autoren beschreiben den von ihnen gewählten Weg dabei als einen Kompromiss zwischen dem Extrem, eine vollständige formale Definition des Fachwissens zu fordern, und dem anderen Extrem, sämtliche Sequenzdiagramme durch heuristische Verfahren auszuwerten. Der gewählte Mittelweg ist, lediglich einige wenige Informationen zu fordern. Diese Informationen umfassen globale Variablen und die Änderung derselben bei den Übergängen im Sequenzdiagramm. Die Änderungen werden als Vor- und Nachbedingungen der einzelnen Operationen angegeben. Abbildung 3 enthält ein Beispiel für die Angabe solcher Bedingungen. cardin, cardhalfway, passwdgiven: Boolean card : Card passwd : Sequence Karte eingeben(c : Card) pre : cardin = false post: cardin = true and card = c Enter password(p : Sequence) pre : passwdgiven = false and p->forall( p->includes(d) =>digit(d)) post: passwdgiven = true and passwd = p... Karte auswerfen() pre : cardin = true post: cardin = false and cardhalfway = true and card = null and passwd = null and passwdgiven = false Abbildung 3. Fachwissen (OCL) Aus den Variablen wird ein Zustandsvektor gebildet, durch den die Zustände im Zustandsdiagramm beschrieben werden. Im Beispiel des Geldautomaten wird der Zustandsvektor folgendermaßen aus den globalen Variablen gebildet: <cardin, cardhalfway, passwdgiven, card, passwd> Im Beispiel der Abbildung 4 ändert der Übergang Karte eingeben den Zustand der Variablen cardin nach true und card zur eingegebenen Karte. Zur Generierung des Zustandsdiagramms werden jeweils gleiche Zustandsvektoren zusammengefasst, die Kanten dazu werden aus den Übergängen der Sequenzdiagramme gebildet. Abbildung 4. Auschnitt eines Sequenzdiagramms mit Zustandsvektoren Zusammenfassung der Zustandsdiagramme Die Zusammenfassung der einzelnen Zustandsdiagramme erfolgt durch die Zusammenlegung gleicher Zustände. Dabei werden zwei Zustände als gleich angesehen, wenn sie den selben Zustandsvektor besitzen, sowie mindestens eine eingehende Kante die selbe Beschriftung trägt. Große Zustandsdiagramme werden schnell schwer überschaubar. Zur besseren Lesbarkeit des Zustandsdiagramms, muss dieses deshalb mit einer Hierarchie angereichert werden. Im vorgestellten Verfahren werden dazu die Zustandsvektoren verwendet. Der Benutzer kann zusätzlich einige Parameter angeben, mit denen das Ergebnis beeinflusst werden kann. Dazu zählen: eine maximale Tiefe der Hierarchie, die maximale Anzahl von Zuständen innerhalb einer Ebene, der maximale Anteil ebenenübergreifender Zustandsübergänge, und eine Reihenfolge der Wichtigkeit einzelner Variablen im Zustandsvektor. Unter Berücksichtigung dieser Parameter werden die Zustandsdiagramme zu einem Diagramm zusammengefasst, das Ebenen enthält, die den Zustand der Variablen der Zustandsvektoren darstellen. Die Lesbarkeit dieses Diagramms wird noch weiter erhöht, durch die Generalisierung von Zustandsübergängen. Das bedeutet, Übergänge werden auf die nächste Ebene gezogen,

5 5 wenn alle darin enthaltenen Zustände diesen Übergang durchführen würden Bewertung Die Autoren liefern mit ihrer Arbeit ein Verfahren, das den Schritt von der Spezifikation zum Entwurf vereinfachen kann und eine direkte Verbindung zwischen den Modellen herstellt. Voraussetzung dafür ist allerdings das Vorhandensein umfangreicher Sequenzdiagramme in der Spezifikation. Zudem müssen diese durch Fachwissen angereichert sein. Dieser Schritt hat nicht viel mit der Spezifikation zu tun, sondern muss dem Entwurf zugeordnet werden. Die Arbeit wurde chronologisch bereits vor dem Verfahren zur Generierung von Sequenzdiagrammen aus Use-Cases geschrieben. Denkbar wäre jedoch, diese beiden Verfahren zu kombinieren, und so von textueller Beschreibung zu Zustandsdiagrammen zu gelangen. Dabei wäre zwischen den Transformationsvorgängen manuelles Eingreifen nötig. Zunächst müssten die generierten Sequenzdiagramme geprüft und vermutlich überarbeitet werden. Vor dem nächsten Transformationsschritt ist zudem noch die Ergänzung des Fachwissens nötig. Das resultierende Zustandsdiagramm kann dann zur weiteren Bearbeitung weiterverwendet werden. Es stellt sich auch hier die Frage nach dem Nutzen des Diagramms. Ein Zustandsdiagramm kann bereits einen großen Teil der Programmlogik enthalten. Bei entsprechender Werkzeugunterstützung kann dieses Modell im MDA-Prozess weiterverwendet werden. Sicherlich wird dazu weitere Verfeinerung und einige weitere Arbeit nötig sein, als Ausgangsbasis kann das Zustandsdiagramm dabei jedoch helfen. Der Aufwand der betrieben werden muss, scheint sich im Rahmen zu halten. Was in der Veröffentlichung von Whittle und Schumann fehlt, ist eine eigene Bewertung und Erfahrungsberichte des Verfahrens. Es bleibt offen, ob das Verfahren bereits in einem Werkzeug eingesetzt wurde und wie zuverlässig es funktioniert. 4 PRODUKTE ZUM MODEL DRIVEN REQUIRE- MENTS ENGINEERING Ohne Werkzeugunterstützung ergibt Model Driven Engineering keinen Sinn. Die Internetseite der OMG nennt über 50 Werkzeuge [5] die MDA unterstützen. Der Funktionsumfang und das Fachgebiet der Werkzeuge unterscheidet sich mit Sicherheit sehr. Der Stand einiger Werkzeuge ist mittlerweile bereits recht weit fortgeschritten und sie haben sich im Praxiseinsatz bewärt. Auch am Open-Source-Bereich ist die Entwicklung des MDA nicht spurlos vorüber gegangen und es stehen verschiedene Produkte zur Verfügung [6]. Die Anforderungserfassung in der MDA findet bisher jedoch weniger Beachtung. In den folgenden Kapiteln werden Produkte betrachtet, die sich speziell mit der Anforderungsanalyse und -spezifikation mit MDA beschäftigen. 4.1 Gebit TREND/Analyst Gebit Solutions ist ein Softwarehaus, das auf die Entwicklung von Java-Anwendungen spezialisiert ist. Gebit verfügt über die eigene Produktlinie TREND, die Werkzeuge zur Anforderungserfassung, Modellierung und Implementierung umfasst. Den Begriff Model Driven Requirements Engineering verwendet Gebit für das Produkt TREND/Analyst. Analyst verfügt über ein eigenes Metamodell, das die möglichen Anforderungsartefakte und ihre Beziehungen beschreibt. Die Anforderungen werden dadurch strukturiert erfasst und können durch entsprechende Transformationen in verschiedene Ausgabeformate wie Pflichtenheft oder Einzelspezifikation umgeformt werden. Dies ist nach Gebit auch die Rechtfertigung zur Nutzung des Begriffs des MDRE. Denkbar ist beispielsweise der Export eines Dokuments mit allen Anwendungsfällen einer bestimmten Projektphase, oder die Erzeugung eines ausführlichen Spezifikationsdokuments zu einem einzelnen Anwendungsfall. Dadurch dass sämtliche Werkzeuge der TREND- Produkte auf dem Eclipse-Framework basieren, arbeiten Entwickler und Analysten in einer homogenen Umgebung und es sind Verknüpfungen zwischen den Modellen möglich. Automatisierte Umwandlungen sind in diesem Produkt nicht vorgesehen. Das bedeutet, dass sich die Verknüpfung der Projektphasen auf die UML-Diagramme und die Nutzung einer gemeinsamen Plattform beschränkt. Trotzdem kann die Nutzung des Produktes sehr sinnvoll sein, wenn bisher lediglich Textdokumente verwendet wurden. Die strukturierte Erfassung der Anforderungen, ergänzt durch die Einbindung von Use-Caseund Ablaufdiagrammen, bedeutet in einem solchen Fall bereits einen sehr bedeutenden Fortschritt. 4.2 Telelogic DOORS und Rhapsody Telelogic gehört zu den größten Produktanbietern im Bereich der Anforderungserfassung, insbesondere mit dem Werkzeug DOORS. Durch die Übernahme von I-Logix mit dem Produkt Rhapsody hat das Unternehmen seine Produktpalette um ein Werkzeug zur Modellbasierten Entwicklung mit UML erweitert. Derzeit befindet sich ein Angebot von IBM zur Übernahme von Telelogic in Prüfung durch die EU-Kommission. IBM könnte mit dieser Übernahme die starke Marktposition im Bereich des Requirements Engineering zusätzlich zu Rational- Produkten weiter ausbauen. Rhapsody ist ein MDA-Werkzeug zur Software- Modellierung in UML 2.1 und SysML. Aus den Modellen kann direkt ausführbare Software exportiert werden und das Werkzeug stellt eine Testumgebung zur Validierung der Modelle zur Verfügung. Entwickelt wurde das Produkt unter anderem vom israelischen Professor David Harel, der vor allem durch seine Arbeit an Zustandsdiagrammen bekannt wurde.

6 6 Telelogic DOORS kommt insbesondere in Großunternehmen zum Einsatz, in denen die Anforderungserfassung auch durch gesetzliche Regelungen vorgeschrieben ist, wie zum Beispiel bei Automobilherstellern. Das Produkt ist aber allgemein weit verbreitet und hat einen Schwerpunkt auf der Nachverfolgbarkeit von Anforderungen. Diese beiden Produkte werden nun durch das Rhapsody Gateway miteinander kombiniert. Dabei können einzelne Elemente des Rhapsody-Modells mit Anforderungen in DOORS verknüpft werden. Mit den beiden Telelogic Produkten stehen offensichtlich zwei ausgereifte Anwendungen zur Verfügung. Der Nachteil dieser Lösung ist die etwas aufwändige Verknüpfungsmöglichkeit. [3] I. Diaz, O. Pastor, and A. Matteo, Modeling interactions using role-driven patterns, in Proc. 13th IEEE International Conference on Requirements Engineering, 29 Aug. 2 Sept. 2005, pp [4] J. Whittle and J. Schumann, Generating statechart designs from scenarios, in Proc. International Conference on Software Engineering, 4 11 June 2000, pp [5] OMG, Omg committed companies, Januar [Online]. Available: [6] P. D. G. Wanner and S. Siegl, Modellgetriebene softwareentwicklung auf basis von open-source-werkzeugen - reif für die praxis, Oktober [7] OMG, Omg sysml vendors, Januar [Online]. Available: Weitere Insbesondere im Zusammenhang mit SysML gibt es aktuelle Entwicklungen im Bereich des Model Driven Requirements Engineering. Die OMG nennt auf ihrer Internetseite zu SysML weitere Hersteller und Produkte [7]: ARTiSAN Software Tools, EmbeddedPlus Engineering, No Magic, Papyrus for SysML, Software Stencils und Sparx Systems. 5 ZUSAMMENFASSUNG & FAZIT Model Driven Requirements Engineering als Teil des Model Driven Engineering klingt zunächst vielversprechend. Bei nüchterner Betrachtung lassen sich durchaus positive Schlüsse ziehen: Verglichen mit der Anforderungserfassung allein durch ein Textdokument ist jede Art von strukturierter Anforderungserfassung ein Fortschritt. Die Bezeichnung Model Driven verdient die Anforderungserfassung jedoch erst, wenn die Anforderungsmodelle mit den Entwurfsmodellen zumindest verknüpft werden können. SysML scheint ein vielversprechender Ansatz dafür zu sein. Voraussetzung für weiter wachsenden Erfolg wird die umfangreiche Werkzeugunterstützung sein. Die beiden vorgestellten Verfahren zur Teilautomatisierung des Übergangs zwischen Anforderungen und ersten Entwurfsmodellen enthalten mit Sicherheit gute Ideen, der Nutzen und die Praxistauglichkeit sind jedoch fraglich. Geht man vom anhaltenden Trend der modellgetriebenen Softwareentwicklung aus, wird dieser weiterhin Auswirkungen auf die Anforderungserfassung haben. Die aktuelle Entwicklung der Werkzeuge und Standards scheint dies zu bestätigen. LITERATUR [1] Wikipedia, Model driven architecture, Januar [Online]. Available: Architecture [2] J. Ludewig and H. Lichter, Software Engineering. Dpunkt Verlag, 2007.