Model Driven Requirements Engineering

Save this PDF as:
 WORD  PNG  TXT  JPG

Größe: px
Ab Seite anzeigen:

Download "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.

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

Model Driven Development im Überblick

Model Driven Development im Überblick Model Driven Development im Überblick Arif Chughtai Diplom-Informatiker (FH) www.digicomp-academy, Seite 1 September 05 Inhalt Motivation Überblick MDA Kleines Beispiel Werkzeuge www.digicomp-academy,

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

Mehr

Inhalt. Motivation Techniken des MDE. Fallbeispiele

Inhalt. Motivation Techniken des MDE. Fallbeispiele ISE-Seminar 2012 Inhalt Motivation Techniken des MDE Computer Aided Software Engineering (CASE) Domain-Specific-Languages (DSL) Model Driven Architecture (MDA) Fallbeispiele Motivation Automatische Codegenerierung

Mehr

Model Driven Architecture

Model Driven Architecture Model Driven Architecture Wilhelm Stephan Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften Seminar Softwareentwicklung in der Wissenschaft Betreuer: Julian Kunkel SommerSemester

Mehr

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes Dozent: G.Döben-Henisch (Version vom 16.April 2005) PPmP VL2 VL2: Softwareprojekt - Anforderungsanalyse Inhalt 1. Struktur eines Softwareprojektes 2. Anforderungsanalyse 1. Struktur eines Softwareprojektes

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Systemdenken und Gestaltungsmethodik System-Modellierung

Systemdenken und Gestaltungsmethodik System-Modellierung Systemdenken und Gestaltungsmethodik System-Modellierung Prof. Dr.-Ing. Stefan Brunthaler TFH Wildau 2008ff Master Telematik Ausgangsbasis Es liegt ein kosten-nutzen-optimales Lösungskonzept vor. Die Architektur

Mehr

Modellierung vonanforderungen

Modellierung vonanforderungen Modellierung vonanforderungen Dehla Sokenou GEBIT Solutions Koenigsallee 75b 14193 Berlin www.gebit.de dehla.sokenou (at) gebit.de Abstract: In der betrieblichen Anwendungsentwicklung werden in vielen

Mehr

Requirements Engineering I

Requirements Engineering I Norbert Seyff Requirements Engineering I UML Unified Modeling Language! 2006-2012 Martin Glinz und Norbert Seyff. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

Aktuelle Fortschritte von MDAbasierten Entwicklungsansätzen im Bereich Fahrerassistenzsysteme

Aktuelle Fortschritte von MDAbasierten Entwicklungsansätzen im Bereich Fahrerassistenzsysteme Fakultät Informatik Institut f ür Angewandte Inf ormatik, Prof essur TIS Aktuelle Fortschritte von MDAbasierten Entwicklungsansätzen im Bereich Fahrerassistenzsysteme Hauptseminar Technische Informationssysteme

Mehr

Einführung in modellgetriebene Softwareentwicklung. 24. Oktober 2012

Einführung in modellgetriebene Softwareentwicklung. 24. Oktober 2012 Einführung in modellgetriebene Softwareentwicklung 24. Oktober 2012 Überblick Was sind die Grundprinzipien der modellgetriebenen Softwareentwicklung? Entwicklung einer MDD-Infrastruktur Modellgetriebene

Mehr

SEA. Modellgetriebene Softwareentwicklung in der BA

SEA. Modellgetriebene Softwareentwicklung in der BA SEA Modellgetriebene Softwareentwicklung in der BA MDA bei der BA Ziele/Vorteile: für die Fachabteilung für die Systementwicklung für den Betrieb Wie wird MDA in der BA umgesetzt? Seite 2 MDA bei der BA

Mehr

Software Factories SS 2016. Prof. Dr. Dirk Müller. 3 Modellgetriebene Softwareentwicklung

Software Factories SS 2016. Prof. Dr. Dirk Müller. 3 Modellgetriebene Softwareentwicklung Software Factories 3 Modellgetriebene Softwareentwicklung Prof. Dr. Dirk Müller Übersicht Einordnung im Lebenszyklus Ziele Hebung des Abstraktionsniveaus Model Driven Architecture (MDA) Domänenspezifische

Mehr

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt

Objektorientierter Software-Entwurf Grundlagen 1 1. Analyse Design Implementierung. Frühe Phasen durch Informationssystemanalyse abgedeckt Objektorientierter Software-Entwurf Grundlagen 1 1 Einordnung der Veranstaltung Analyse Design Implementierung Slide 1 Informationssystemanalyse Objektorientierter Software-Entwurf Frühe Phasen durch Informationssystemanalyse

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Requirements Engineering I

Requirements Engineering I Martin Glinz Requirements Engineering I Kapitel 9 UML Unified Modeling Language Universität Zürich Institut für Informatik 2006, 2008 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind

Mehr

Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien. Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009

Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien. Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009 Die MID ModellierungsMethodik M³ ein Baukasten für Produktlinien Andreas Ditze, MDD & PL 2009, Leipzig, 23.03.2009 I N H A L T 1. Vorstellung 2. Was macht einen guten Baukasten aus? 3. Ziele der MID ModellierungsMethodik

Mehr

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Softwarearchitekturen I Softwareentwicklung mit Komponenten

Softwarearchitekturen I Softwareentwicklung mit Komponenten Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem

Mehr

MDA-Praktikum, Einführung

MDA-Praktikum, Einführung MDA-Praktikum, Einführung Prof. Dr. Peter Thiemann Universität Freiburg 02.11.2005 Was ist MDA? MDA = Model-Driven Architecture Initiative der OMG Object Management Group: CORBA, UML,... offenes Firmenkonsortium

Mehr

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

Mehr

Produktskizze. 28. November 2005 Projektgruppe Syspect

Produktskizze. 28. November 2005 Projektgruppe Syspect 28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der

Mehr

Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management

Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management REConf Schweiz 2010 IIBA BABOK 2.0 Wortzählung 1729 "Requirement" = 42% von ( Requirement + Business + Solution

Mehr

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting

Modellierungstechniken im Softwaredesign. Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Modellierungstechniken im Softwaredesign Praxisprojekt [ai] Control WS 2011/2012 Lara Baschour und Anne Heiting Was ist Modellierung? Modell = Ein Modell ist eine Repräsentation eines Systems von Objekten,

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis

Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0. Für den Einsatz in der Praxis Guido de Melo 5.2.2007 Fachvortrag, Uni Ulm UML 2.0 Für den Einsatz in der Praxis Seite 2 Überblick 1. Ziele 2. Warum das alles? 3. Was ist UML 4. Diagrammarten 5. Umfeld Seite 3 1. Ziele 1. Ziele dieses

Mehr

Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011

Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011 Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen OOP München, 26.01.2011 I N H A L T 1. SOA das erste Projekt 2. Prozesse Ergebnisse aus dem Fachbereich 3. Der Business Analyst und BPMN

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Gliederung des Vortrages

Gliederung des Vortrages Gliederung des Vortrages Unified Modeling Language Rational Rose Sergej Schwenk Oktober 1999 0. Einführung 1. Historie 2. Der Entwicklungsprozeß 3. UML 3.1 Anwendungsfalldiagramme 3.2 Klassendiagramme

Mehr

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen

Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Ein Erfahrungsbericht beim Einsatz von generierenden Ansätzen im Vergleich zu generischen Lösungen Tom Krauß Agenda Begriffsdefinition Verfahren Praktische Beispiele Vergleich und Bewertung Begriffsklärung

Mehr

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Übersetzung von UML-Software-Spezifikationen in Simulationsmodelle

Übersetzung von UML-Software-Spezifikationen in Simulationsmodelle Übersetzung von UML-Software-Spezifikationen in Simulationsmodelle Stefan Walter swalter@dspace.de Lehrstuhl für Informationstechnik, insb. Realzeitsysteme FernUniversität in Hagen Fachtagung Echtzeit

Mehr

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement

IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement IT-Projekte effektiv steuern durch Integration von Modellierung und ALM bzw. Änderungsmanagement Basierend auf einem zentralen SOA-Projekt wird die Integration von Änderungsmanagement aus dem ApplicationLifeCycle

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

UML 2.0 Quelltextgenerierung

UML 2.0 Quelltextgenerierung UML 2.0 Quelltextgenerierung Seminararbeit im Fach Informatik im Rahmen des Seminars Sicherheitskritische Systeme an der Universität Siegen, Fachgruppe für Praktische Informatik eingereicht bei Dr. Jörg

Mehr

Requirements Engineering I

Requirements Engineering I Martin Glinz Requirements Engineering I Kapitel 9 UML Unified Modeling Language Universität Zürich Institut für Informatik 2006, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Von UML 1.x nach UML 2.0

Von UML 1.x nach UML 2.0 Zürich Soft Summer 2005 Fortgeschrittene Aspekte der Software Technologie Von UML 1.x nach UML 2.0 Prof. Dr. Martin Glinz www.ifi.unizh.ch/req Ergänzendes Material zur Vorlesung Spezifikation und Entwurf

Mehr

SysML Die Zukunft des Systems Engineering?

SysML Die Zukunft des Systems Engineering? ECC 2012 Winterthur 5. Juni 2012 SysML Die Zukunft des Systems Engineering? Omar Naas, Senior Consultant, EVOCEAN GmbH 1934 Citroën 2CV Citroën Direktor Pierre-Jules Boulanger definierte 7 Anforderungen,

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

Mehr

Methodische objektorientierte Softwareentwicklung

Methodische objektorientierte Softwareentwicklung Methodische objektorientierte Softwareentwicklung Eine Integration klassischer und moderner Entwicklungskonzepte von Mario Winter 1. Auflage Methodische objektorientierte Softwareentwicklung Winter schnell

Mehr

UML (Unified Modelling Language) von Christian Bartl

UML (Unified Modelling Language) von Christian Bartl UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...

Mehr

Comparing Software Factories and Software Product Lines

Comparing Software Factories and Software Product Lines Comparing Software Factories and Software Product Lines Martin Kleine kleine.martin@gmx.de Betreuer: Andreas Wuebbeke Agenda Motivation Zentrale Konzepte Software Produktlinien Software Factories Vergleich

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Vorlesung "Software-Engineering"

Vorlesung Software-Engineering Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse

Mehr

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr

(Titel des Berichts)

(Titel des Berichts) (Titel des Berichts) Praxissemesterbericht von (Vorname Name) aus (Geburtsort) Matrikelnummer Anschrift Telefon HTW Aalen Hochschule für Technik und Wirtschaft Betreuender Professor Abgabetermin Angaben

Mehr

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit

Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit Was ist EMF? Wie wird EMF eingesetzt? Was ist ecore? Das Generatormodell Fazit EMF ist ein eigenständiges Eclipse-Projekt (Eclipse Modeling Framework Project) EMF ist ein Modellierungsframework und Tool

Mehr

NACHRICHTENTECHNISCHER SYSTEME

NACHRICHTENTECHNISCHER SYSTEME Einführung UML COMPUTERSIMULATION NACHRICHTENTECHNISCHER SYSTEME 11. Unified Modeling Language UML 220 Standardsprache d zur Visualisierung, i Spezifikation, Konstruktion und Dokumentation komplexer (Software-)

Mehr

FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK

FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK DIE METHODE FÜR DEN SOFTWAREENTWURF VERNETZTER MECHATRONISCHER SYSTEME Innovative Funktionen moderner mechatronischer

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

10. Modellgetriebene Entwicklung Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

10. Modellgetriebene Entwicklung Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 10. Modellgetriebene Entwicklung Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik:

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

Jochen Bauer 08.01.2010

Jochen Bauer 08.01.2010 08.01.2010 Um was geht s und wie läuft s ab? Eclipse-EMP-MDT: Standards unter einem Dach! Gliederung 1. der Model (MDT) 2. Model-Driven- (MDD) und MDT 3. Interne Domain-Specific-Languages (DSL) 4. 5. 6.,

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Requirements-Management Ein praktisches Beispiel

Requirements-Management Ein praktisches Beispiel 2003 Eurocopter Deutschland GmbH 2003 Requirements-Management Ein praktisches Beispiel a.s.drexler@t-online.de Softwareprozesse in Luft- und Raumfahrtprojekten Workshop der DGLR am 15.10.2003 Der Vortrag

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

MDSD in der Praxis. Dr. Shota Okujava.

MDSD in der Praxis. Dr. Shota Okujava. MDSD in der Praxis Dr. Shota Okujava shota.okujava@isento.de www.isento.de Agenda Einführung/Begriffsdefinition Softwareentwicklungsprozess und MDSD Technologien und Werkzeuge Probleme und Herausforderungen

Mehr

Motivation. Motivation

Motivation. Motivation Vorlesung Modellierung nebenläufiger Systeme Sommersemester 2012 Universität Duisburg-Essen Was sind nebenläufige Systeme? Ganz allgemein: Systeme, bei denen mehrere Komponenten/Prozesse nebenläufig arbeiten

Mehr

Dokumentation Projekt Virtuelles Tagebuch

Dokumentation Projekt Virtuelles Tagebuch Priv.Doz. Dr. Michael Hahsler Institut für Informationswirtschaft Dokumentation Projekt (Matr. Nr. 9806106) - 1 - 1 Problembeschreibung Das Ziel dieses Projektes ist es, ein Tagebuch in elektronischer

Mehr

INSPIRE - Modellierung

INSPIRE - Modellierung INSPIRE - Modellierung Inhalt Motivation Modellierung UML Diagramme INSPIRE-Schulung LKROS 2 Motivation Was ist ein Modell, und warum wollen wir modellieren? Warum brauchen wir eine Modellierungssprache

Mehr

(BABOK-v3-Technik 10.41)

(BABOK-v3-Technik 10.41) (BABOK-v3-Technik 10.41) Allgemeines Scope-Modelling gibt Antworten auf die Fragen Was gehört zum System und was nicht? sowie Woher kommen die Anforderungen? Diese Fragen sollten generell zu Beginn jeder

Mehr

14 Aktivitäten und Artefakte

14 Aktivitäten und Artefakte Im Rahmen einer Softwareentwicklung müssen Aktivitäten durchgeführt werden, die zu Ergebnissen im Folgenden Artefakte (artifacts) genannt führen. Eine Aktivität wird durch Mitarbeiter ausgeführt, die definierte

Mehr

MODELLGETRIEBENE SOFTWAREENTWICKLUNG: ALLES UML, ODER?

MODELLGETRIEBENE SOFTWAREENTWICKLUNG: ALLES UML, ODER? 1 2 MODELLGETRIEBENE SOFTWAREENTWICKLUNG: ALLES UML, ODER? Bei modellgetriebener Softwareentwicklung werden aus kompakten Modellbeschreibungen lauffähige Softwareprogramme generiert. Solche Modellbeschreibungen

Mehr

24 Transformation der Anforderungsspezifikation

24 Transformation der Anforderungsspezifikation 271 24 Transformation der Anforderungsspezifikation 24.1 Einleitung Bei der Softwarespezifizierung wird die Anforderungsspezifikation überarbeitet, weiter strukturiert und präzisiert, um eine Basis für

Mehr

Seminar Bassem Ben Helal

Seminar Bassem Ben Helal Requiline Seminar Bassem Ben Helal Inhalt Motivation Kernfunktionalitäten Architektur Hierarchie Typen Abhängigkeiten Variabilitätspunkte Produktkonfiguration Evaluierung Demo Diskussion Motivation RequiLine

Mehr

Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement

Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement Verwendung von Anforderungsbasierten Verfolgbarkeitsmetriken im Projektmanagement Michael Eisenbarth Abteilung Requirements- und Usability-Engineering Fraunhofer-Institut für Experimentelles Software Engineering

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung

ZENITY - Die Software für Ihre Unternehmens-Releaseplanung ZENITY - Die Software für Ihre Unternehmens-Releaseplanung RELEASEPLANUNG HEUTE Heutige Anwendungen in in Grossunternehmen sind sind keine keine alleinstehenden alleinstehenden Insel-Applikationen Insel-Applikationen

Mehr

Bei der Übertragung eines 3D-Modells zwischen zwei CAD-Anwendungen verlieren Sie Stunden oder sogar Tage beim Versuch, saubere Geometrie zu erhalten

Bei der Übertragung eines 3D-Modells zwischen zwei CAD-Anwendungen verlieren Sie Stunden oder sogar Tage beim Versuch, saubere Geometrie zu erhalten Bei der Übertragung eines 3D-Modells zwischen zwei CAD-Anwendungen verlieren Sie Stunden oder sogar Tage beim Versuch, saubere Geometrie zu erhalten und einfachste Änderungen vorzunehmen. An der Arbeit

Mehr

Herausforderungen beim verteilten RE: Ergebnisse einer Umfrage

Herausforderungen beim verteilten RE: Ergebnisse einer Umfrage Herausforderungen beim verteilten RE: einer Umfrage Andrea Herrmann, Timea Illes-Seifert, Michael Geisser, Tobias Hildenbrand Institut für Informatik Neuenheimer Feld 326 69120 Heidelberg, Germany http://www-swe.informatik.uni-heidelberg.de

Mehr

Requirements Lifecycle Management (RLM)

Requirements Lifecycle Management (RLM) Whitepaper Requirments Lifecycle Management Requirements Lifecycle Management (RLM) Die Weiterentwicklung der klassischen Anforderungsanalyse 1 Einleitung War noch vor einiger Zeit die klassische Anforderungsanalyse

Mehr

Die Unified Modeling Language UML

Die Unified Modeling Language UML Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 4 Die Unified Modeling Language UML Universität Zürich Institut für Informatik Inhalt 4.1 Hintergrund 4.2 Grundkonzepte der UML 4.3 Die Rolle

Mehr

Modellgetriebene Softwareentwicklung und deren Auswirkung auf die Entwicklungsmethodologie von Standardsoftware

Modellgetriebene Softwareentwicklung und deren Auswirkung auf die Entwicklungsmethodologie von Standardsoftware Hochschule Heilbronn Fakultät Wirtschaft 1 Studiengang Electronic Business Diplomarbeit Modellgetriebene Softwareentwicklung und deren Auswirkung auf die Entwicklungsmethodologie von Standardsoftware Vorgelegt

Mehr

Anforderungsmanagement

Anforderungsmanagement Gerhard Versteegen (Hrsg.) Alexander Heßeier Colin Hood Christian Missling Renate Stücka Anforderungsmanagement Formale Prozesse, Praxiserfahrungen, Einführungsstrategien und Toolauswahl Springer Inhaltsverzeichnis

Mehr

Software Engineering Klassendiagramme Assoziationen

Software Engineering Klassendiagramme Assoziationen Software Engineering Klassendiagramme Assoziationen Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Lesen von Multiplizitäten (1) Multiplizitäten werden folgendermaßen

Mehr

Unified Modeling Language 2

Unified Modeling Language 2 Unified Modeling Language 2 Marvin Frommhold 17.11.2008 Gliederung Einleitung Geschichte Strukturierung der Spezifikation Diagrammtypen Strukturdiagramme Verhaltensdiagramme CASE-Werkzeuge Quellen Was

Mehr

Softwaretechnologie - Wintersemester 2011/12 - Dr. Günter Kniesel

Softwaretechnologie - Wintersemester 2011/12 - Dr. Günter Kniesel Übungen zur Vorlesung Softwaretechnologie - Wintersemester 2011/12 - Dr. Günter Kniesel Übungsblatt 4 - Lösungshilfe Aufgabe 1. Zustandsdiagramm (6 Punkte) Geben Sie ein Zustandsdiagramm für den Lebenszyklus

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Rhapsody in C ein System zur aspektorientierten Embedded- Entwicklung? Dr.- Ing. Alexander Steinkogler B. Braun Melsungen AG

Rhapsody in C ein System zur aspektorientierten Embedded- Entwicklung? Dr.- Ing. Alexander Steinkogler B. Braun Melsungen AG Rhapsody in C ein System zur aspektorientierten Embedded- Entwicklung? Dr.- Ing. Alexander Steinkogler B. Braun Melsungen AG Einführung Was sind Aspekte? Anforderungen: Thema / Aspekt Berühren viele andere

Mehr

Web Engineering-Seminar Methoden zur Web Modellierung: Object-oriented Hypermedia Method (OO-H)

Web Engineering-Seminar Methoden zur Web Modellierung: Object-oriented Hypermedia Method (OO-H) Web Engineering-Seminar Methoden zur Web Modellierung: Object-oriented Hypermedia Method (OO-H) Dominik Kirsten Daniel Schäferbarthold Trier, 21.01.2008 1 Gliederung 1. Einführung 1.1 Anforderungen an

Mehr