2.4 Sequenzdiagramm. Beziehung und Beispiel. Instantiierbare Anwendungsfälle. Akteur kommuniziert. A und B, da die Kommunikationsbeziehung

Größe: px
Ab Seite anzeigen:

Download "2.4 Sequenzdiagramm. Beziehung und Beispiel. Instantiierbare Anwendungsfälle. Akteur kommuniziert. A und B, da die Kommunikationsbeziehung"

Transkript

1 2.4 Sequenzdiagramm 109 Beziehung und Beispiel B is-a A Termin ändern is-a Eintrag ändern (Akteur = Benutzer) Instantiierbare Anwendungsfälle A und B. Falls A wie im Beispiel abstrakt ist: nur B. Akteur kommuniziert mit A und B, da die Kommunikationsbeziehung von A geerbt wird Tab. 2 8 Beziehungen zwischen Anwendungsfällen B A B «extend» A Terminvorschlag finden «extend» Termin erfassen (Akteur = Benutzer) A, A gemeinsam mit B und fallweise auch B. Im Beispiel bezeichnet B (Terminvorschlag finden) das erweiternde»delta«, das in unserem Beispiel keinen eigenen Anwendungsfall darstellt. Häufig wird aber für B ein Name gewählt, der»b + Delta«entspricht (etwa Place rush order «extend» Place order [Booc99]), und dadurch instantiierbar klingt. A und B. Dies ist zwar formal nicht ableitbar (Abhängigkeiten weisen keine Vererbungssemantik auf), hat sich jedoch so eingebürgert. Im Beispiel würde daher keine zweite Beziehung zwischen dem Akteur und Terminvorschlag finden eingezeichnet. B «extend» A A «include» B Termin erfassen (Akteur = Benutzer) «include» Teilnehmer verständigen A gemeinsam mit B und fallweise auch B. A A «include» B 2.4 Sequenzdiagramm Im vorhergehenden Unterkapitel wurde gezeigt, wie durch das Anwendungsfalldiagramm ein Überblick über die Funktionalität eines betrachteten Systems gegeben werden kann. Dabei standen strukturelle Zusammenhänge im Vordergrund das dynamische Systemverhalten konnte allenfalls verbal beschrieben werden. Im vorliegenden Unterkapitel treten wir nunmehr in die Diskussion der diagrammatischen Verhaltensdarstellung ein: Mit Sequenz-, Kollaborations-, Zustands- und Aktivitätsdiagrammen können unterschiedliche Aspekte des Systemverhaltens modelliert werden. Das Sequenzdiagramm wurde ursprünglich zur Modellierung von Telekommunikationssystemen entwickelt (Message Sequence Charts Kollaborationsdiagramm S. 117 Zustandsdiagramm S. 128 Aktivitätsdiagramm S. 151

2 110 2 UML Syntax und Semantik Sequenzdiagramm (sequence diagram)... zur exemplarischen Darstellung eines Ablaufs (= Szenario) Algorithmus vs. Szenario Aktivitätsdiagramm S. 151 [CCIT88]) und von Rumbaugh et al. zur Erstellung dynamischer Modelle objektorientierter Systeme in OMT eingeführt [Rumb91]. In UML wurde schließlich eine Version des Sequenzdiagramms übernommen, die in wesentlichen Teilen auf die von Buschmann et al. erweiterte Notation (Object Message Sequence Charts) zurückgeführt werden kann [Busc96]. Das Sequenzdiagramm beschreibt das sogenannte Interobjektverhalten, das ist die Art und Weise, wie einzelne Objekte miteinander Nachrichten austauschen (»interagieren«), um ein bestimmte Aufgabe zu erfüllen. Gemeinsam mit dem im nächsten Abschnitt vorgestellten Kollaborationsdiagramm wird es in UML daher auch als Interaktionsdiagramm bezeichnet. Sequenzdiagramme eignen sich primär zur exemplarischen Darstellung eines Ablaufs, die genau einen möglichen Ablauf eines Anwendungsfalls oder einer Operation, d.h. ein mögliches Szenario, beschreibt. Der Vorteil der Szenariosicht ist die Konzentration auf das Wesentliche durch Weglassen von Ausnahmen und Spezialfällen. Grundsätzlich besteht wohl auch die Möglichkeit der Modellierung von Fallunterscheidungen und Wiederholungen, womit Szenarien soweit verallgemeinert werden können, daß sie vollständige Algorithmen darstellen. Allerdings ist dies erfahrungsgemäß ein sehr mühsames Unterfangen, das u.u. auch zu relativ unleserlichen Diagrammen führen kann. Die Autoren empfehlen daher, Sequenzdiagramme für exemplarische Verhaltensdarstellungen einzusetzen und echte Algorithmen eher mit Aktivitätsdiagrammen oder außerhalb von UML, etwa in Pseudocode, zu notieren. Im Sequenzdiagramm werden zwei Darstellungsdimensionen unterschieden: Die vertikale Dimension entspricht einer Zeitachse, während horizontal die betrachteten Objekte aufgetragen werden. Objektsymbol Lifeline Zeitachse vertikal und ordinal skaliert Aktivierungsbalken (activation bar) Löschsymbol einx:x Wenn es sich als darstellungstechnisch günstiger erweist, kann ein Sequenzdiagramm auch um 90 gedreht angeordnet werden. Wir gehen im folgenden jedoch immer von der»klassischen«form aus. Durch die Einführung einer expliziten Zeitachse mit von oben nach unten fortschreitender Zeit kann die chronologische Reihenfolge von Nachrichten durch deren vertikale Anordnung im Diagramm definiert werden. Die Zeitachse ist im Normalfall ordinal skaliert, d.h., daß die Größe vertikaler Abstände keinerlei Bedeutung hat. Für die Modellierung von Echtzeitverarbeitung ist allerdings auch eine metrisch skalierte Zeitachse zulässig. Die an der Interaktion teilnehmenden Objekte werden horizontal nebeneinander durch je eine vertikale, strichlierte Linie repräsentiert, die sich über die»lebenszeit«des Objekts erstreckt. Am oberen Ende dieser Lifeline (die Bezeichnung wird als Jargonausdruck aus dem

3 2.4 Sequenzdiagramm 111 Original übernommen) ist ein Objektsymbol angebracht, das i.a. lediglich Name und Klasse des Objekts enthält. Wird eine Operation eines Objekts ausgeführt, so wird für die Dauer dieser Operation die Lifeline zu einem sogenannten Aktivierungsbalken verbreitert. Hört ein Objekt im Zuge der beschriebenen Interaktion auf zu existieren, werden Lifeline bzw. Aktivierungsbalken bis zu dieser Stelle verkürzt und durch ein Kreuz abgeschlossen. Ansonsten erstreckt sich die Objektdarstellung bis an das untere Ende des Sequenzdiagramms. Objekte, die über einen eigenen Kontrollfluß (Prozeß oder Thread) verfügen, werden aktive Objekte genannt und durch Objektsymbole mit fettem Rahmen repräsentiert (alternativ dazu kann die Eigenschaft {active} explizit angegeben werden). Sie können unabhängig von anderen Objekten operieren und werden dementsprechend mit durchgehenden Aktivierungsbalken ausgestattet. (Weitere Hinweise über aktive Objekte finden sich im Unterkapitel über Kollaborationsdiagramme.) Die Beschreibung der Interaktion zwischen den Objekten basiert auf der Angabe der Nachrichten, die zwischen den Objekten ausgetauscht werden. Diese werden normalerweise durch horizontale Pfeile notiert, die sich von der Lifeline des Senderobjekts zu jener des Empfängerobjekts erstrecken. Die Nachrichtenübermittlung wird dabei i.a. als konzeptionell verzögerungsfrei betrachtet. Sollte dies eine unzulässige Modellvereinfachung darstellen, können Nachrichtenpfeile auch abwärts gerichtet sein und damit auf zeitkonsumierende Übermittlung hinweisen (vgl. Abb. 2 63, S. 117). Die Form der Pfeilspitze gibt Aufschluß über die Art der Nachrichtenübermittlung. UML unterscheidet die folgenden Arten (weitere Varianten wären als Erweiterungen von UML zulässig): Aktives Objekt (active object) S. 123 Horizontale Pfeile stehen für Nachrichten, die ohne Zeitverlust übermittelt werden, abwärts gerichtete Pfeile repräsentieren Nachrichten mit Übermittlungszeit > 0 Synchroner Kontrollfluß, d.h., die Nachricht wird als Prozeduraufruf interpretiert, asynchroner Kontrollfluß, d.h., die Nachricht wird als Signal betrachtet, und der Sender der Nachricht wartet nicht auf die Antwort des Empfängers, sowie unspezifizierter Kontrollfluß. Kontrollflußvarianten: synchron asynchron unspezifiziert Zusätzlich können Rücksprung-Anweisungen durch strichlierte Pfeile notiert werden. In nebenläufigen Systemen kann die Zuordnung von Nachrichten zu einem bestimmten Kontrollfluß (Prozeß oder Thread) durch Vergabe von Nachrichtennummern eines bestimmte Formats erfolgen. Da die Angabe von Sequenznummern für Nachrichten in einem Sequenzdiagramm aber eher die Ausnahme darstellt schließlich wird die Reihenfolge durch die Zeitachse i.a. eindeutig bestimmt, wird dieser Mechanismus, der gleichermaßen (und vor allem) bei Kollabo- Rücksprung: Numerierung von Nachrichten S. 120

4 112 2 UML Syntax und Semantik Objekterzeugung new() Überwachungsbedingung (guard condition) [...] [B] m() [ B] n() Verzweigung Alternative Lifelines [B] m() [ B] n() rationsdiagrammen anwendbar ist, erst im nächsten Unterkapitel erläutert. Wird ein Objekt erst im Laufe der Interaktion auf Grund einer Nachricht wie new(), create() o.ä. erzeugt, so mündet der Pfeil dieser»erzeugenden«nachricht direkt im Symbol des Objekts, das in diesem Fall nicht am oberen Rand des Sequenzdiagramms, sondern eben erst auf jener Höhe plaziert ist, die dem Zeitpunkt seiner Erzeugung entspricht. Nachrichten können durch Überwachungsbedingungen beschriftet sein, womit Fallunterscheidungen im Sequenzdiagramm sichtbar gemacht werden: Die»überwachte«Nachricht wird nur übermittelt, wenn die in eckigen Klammern angegebene Bedingung erfüllt ist. Häufig werden durch zwei zu einander komplementäre Bedingungen alternative Nachrichten im Sinne einer if-then-else-verzweigung markiert. Dabei ist es aus Platzgründen i.a. nicht möglich, beide Nachrichtenpfeile horizontal zu führen, weshalb zwangsläufig einer der Pfeile abwärts zeigt. Um einen derartigen Pfeil von einem»zeitkonsumierenden«pfeil (s.o.) zu unterscheiden, wird er abgeknickt notiert, sodaß ein Pfeilsegment dennoch horizontal geführt werden kann und an die Unmittelbarkeit der Übertragung erinnert. Werden ein und demselben Objekt als direkte oder indirekte Folge einer solchen Verzweigung unterschiedliche Nachrichten übermittelt, wird seine Lifeline aufgespalten, um zu betonen, daß für dieses Objekt alternative»interaktionspfade«dargestellt werden. Am Ende einer solchen Alternative können die Lifeline-Zweige wieder verschmolzen werden. Als Beispiel aus dem CALENDARIUM wenden wir uns der Beschreibung eines Standardablaufs des Anwendungsfalls Termin löschen zu. Dabei gehen wir von einem zu löschenden Termin mit zwei Teilnehmern und einer Vorabbenachrichtigung (»Notifikation«) aus. Von den beiden Teilnehmern sei einer der handelnde Akteur, der zweite sei zum Zeitpunkt der Absage ebenfalls»on-line«. Beide Teilnehmer sollen durch ein Informationsfenster von der erfolgten Terminabsage informiert werden.

5 2.4 Sequenzdiagramm 113 b1 :Benutzer :Termin- Maske :Termin :CALEN- DARIUM :Notifikation :Queue t1 :Teilnehmer t2 :Teilnehmer b2 :Benutzer lösche! loesche() benutzer() [b ist nicht berechtigt] b [b ist berechtigt] loesche() deq(id) loesche(self) Abbruch info(self, termin) [on-line] new(hinweis) Hinweis f1 :Infofenster loesche(self) info(self, termin) [on-line] new(hinweis) f2 :Infofenster Hinweis ok! ok! Abbildung 2 61 zeigt ein entsprechendes Sequenzdiagramm, wobei vorausgesetzt wird, daß sich der agierende Benutzer b1 in einer Situation befindet, in der der zu löschende Termin durch eine entsprechende Benutzerschnittstelle (Objekt :TerminMaske) repräsentiert wird. Diesem Objekt»sendet«der Benutzer die»nachricht«lösche!, durch die die Ausführung des Anwendungsfalls initiiert wird. Die Nachrichtenübermittlung zwischen dem Menschen und dem System wird dabei typischerweise durch einen Pfeil der Kategorie»unspezifiziert«modelliert. Die Benutzerschnittstelle leitet die Löschanforderung (durch einen synchronen Operationsaufruf) an das ihr zugeordnete Terminobjekt weiter. Dieses wird dadurch aktiv (vgl. den Aktivierungsbalken) und vergewissert sich zunächst, ob der initiierende Benutzer zum Löschen überhaupt berechtigt ist. Dazu fragt es das globale Kontrollobjekt der Klasse CALENDARIUM nach dem aktuellen Benutzer. Dieses Kontrollobjekt, das während der gesamten Sitzung aktiv ist, wird durch die Nachricht benutzer() erneut aktiviert, was durch den nach rechts versetzten, zusätzlichen Aktivierungsbalken dargestellt wird. Das Ergebnis dieser Operation ist die Abb Sequenzdiagramm für das Löschen eines Termins Szenariodarstellung

6 114 2 UML Syntax und Semantik Fallunterscheidung führt zu komplexer Notation: Abbruch durch alternativen Rücksprungpfeil (nach links), auf den die Nachricht»Abbruch«an den Benutzer folgt und die Interaktion beendet wird Szenario-Darstellung... Benutzeridentifikation b, mit deren Hilfe die Berechtigung geprüft werden kann. Diese Prüfung ist in der Abbildung nicht dargestellt, sehr wohl aber die resultierende Fallunterscheidung durch die Überwachungsbedingung [b ist berechtigt]. Diese Bedingung bezieht sich streng genommen nur auf die ihr unmittelbar zugeordnete Nachricht loesche(), wobei im negativen Fall der Anwendungsfall abgebrochen wird, weshalb die Bedingung implizit auch auf die folgenden Nachrichten zutrifft. Als nächstes wird die (einzige) Notifikation gelöscht und im Zuge dessen aus der Warteschlange der noch zu versendenden Notifikationen ausgetragen (deq(id)). Diese Warteschlange kann durch ein externes System repräsentiert sein, weshalb wir hier von asynchroner Nachrichtenübermittlung ausgehen. Die Abarbeitung der Operation Notifikation::loesche() endet damit, daß das Notifikations-Objekt entfernt wird. Als nächstes informiert das Termin- Objekt sein erstes Teilnehmer-Objekt t1, daß das Termin-Objekt gelöscht wird. t1 wiederum veranlaßt das Kontrollobjekt :CALEN- DARIUM zu prüfen, ob der von ihm repräsentierte Benutzer (im Szenario: b1) on-line ist (was der Fall ist), und gegebenenfalls ein Benachrichtigungsfenster zu erzeugen, das vom entsprechenden Benutzer durch die Nachricht ok! zu quittieren ist. Dasselbe erfolgt für den zweiten Teilnehmer t2 und seinen korrespondierenden Benutzer b2, der im vorliegenden Szenario an anderer Stelle on-line ist. Nachdem beide Teilnehmer-Objekte behandelt worden sind, werden das Termin-Objekt und in der Folge auch die zugehörige Benutzerschnittstelle tatsächlich gelöscht. Dieses Beispiel zeigt einen beinahe puristischen Fall eines Szenarios, also einer exemplarischen Verhaltensbeschreibung. Für alle mehrfach auftretenden Objekte werden konkrete Anzahlen festgelegt (eine Notifikation, zwei Teilnehmer), und für die angeführten Bedingungen (etwa [on-line]) sind kaum Alternativen vorgesehen. Eine Ausnahme stellt die Berechtigungsprüfung dar, für die zwei mögliche Ausgänge dargestellt sind (was nach Meinung der Autoren bereits genügt, um das Diagramm optisch zu überfrachten...). Andererseits bringt die an sich übersichtlichere exemplarische Sichtweise auch Nachteile mit sich: Wo Vielfachheiten durch konkrete Anzahlen festgelegt sind, geht entweder der Eindruck der Vielfachheit verloren (im Beispiel: genau eine Notifikation), oder es führt die Wiederholung von Teilsequenzen zu erheblichem Zusatzaufwand für Zeichner und Leser (im Beispiel: zwei Teilnehmer). Als Alternativlösung wird in Abbildung 2 62 derselbe Sachverhalt mit Hilfe von Iterationen beschrieben. Eine zu wiederholende Nachrichten-Teilsequenz ist durch ein Rechteck zu einem Block zusammengefaßt, der im unteren Bereich Angaben zur Schleifensteuerung enthält.

7 2.4 Sequenzdiagramm 115 b1 :Benutzer lösche! :Termin- Maske loesche() :Termin t :Teilnehmer benutzer() :CALEN- DARIUM n:notifikation :Queue :Benutzer Abb Sequenzdiagramm für das Löschen eines Termins algorithmische Darstellung [b ist nicht berechtigt] b loesche() deq(id) für alle Notifikationen n loesche(self) Abbruch für alle Teilnehmer t info(self, termin) [on-line] new(hinweis) f :Infofenster Hinweis ok! für alle InfoFenster f Die Hauptschwierigkeit bei dieser Darstellung liegt darin, den Gültigkeitsbereich der innerhalb der Schleife benützten»lokalen«objekte sauber zu definieren. Im Beispiel stellen die Notifikation n, der Teilnehmer t und der zugehörige Akteur :Benutzer derartige Objekte dar. Anders als das innerhalb der Schleife erzeugte Fensterobjekt f existieren sie bereits von Beginn an, weshalb die Objektsymbole im Diagramm ganz oben angeordnet werden. Ihre Bedeutung erhalten sie aber erst während der entsprechenden Schleifendurchläufe durch ein in UML nicht näher spezifiziertes»binden«der Objekte an Schleifenvariablen (für alle Teilnehmer t...), oder überhaupt nur implizit (die physische Entsprechung :Benutzer des logischen Teilnehmers t ko-iteriert mit t). In Abbildung 2 62 tritt darüber hinaus noch ein anderes Problem auf: Innerhalb der zweiten Schleife werden iterativ Objekte f der Klasse InfoFenster erzeugt, die später ebenfalls in einer Schleife durch Benutzerinteraktionen wieder entfernt werden. Die Vielfach-...vs. algorithmischer Darstellung

8 116 2 UML Syntax und Semantik heit des Fensterobjekts muß dazu aus dem erzeugenden Schleifenblock in den eliminierenden Schleifenblock»hinübergerettet«werden, was einen semantisch eher zweifelhaften Umstand darstellt. Insgesamt wird man immer wieder feststellen, daß ein realistischer, nichttrivialer Algorithmus durch ein Sequenzdiagramm nicht sinnvoll darstellbar ist. Es wird daher empfohlen, Sequenzdiagramme primär für Szenarien zu verwenden, Faustregeln zur Verwendung von Sequenzdiagrammen Ablaufvarianten allenfalls durch mehrere, einander ergänzende Sequenzdiagramme zu modellieren und Verzweigungen und Schleifen sehr sparsam einzusetzen nur dann, wenn das Diagramm eindeutig interpretierbar bleibt. Beschriftung der Marginalie Sequenzdiagramme können an ihrem (i.a. linken) Rand mit zusätzlichen textuellen Angaben ausgestattet sein, die sich auf die Nachrichten bzw. Aktivierungen beziehen, mit denen sie vertikal ausgerichtet sind. Vorgesehen sind u.a.: Zeitbezogene Einschränkung {n.receivetime - n.sendtime < 1sec} Transitionszeit (transition time) Pseudocode Einschränkungen: Wie üblich werden Einschränkungen als logische Ausdrücke in geschwungenen Klammern angegeben. Bei Sequenzdiagrammen, die Echtzeitsysteme beschreiben, beziehen sich Einschränkungen häufig auf Transitionszeiten, indem z.b. die maximal erlaubte Dauer einer Nachrichtenübermittlung angegeben wird. Zu diesem Zweck können Sendebzw. Empfangszeitpunkt einer Nachricht n explizit referenziert werden: n.sendtime und n.receivetime (diese»pseudoattribute«haben die ehemaligen Transitionszeiten abgelöst, die als symbolische Namen ebenfalls in der Marginalie notiert wurden). Auszuführende Aktionen: Bei Bedarf können Aktionen oder Teile eines Algorithmus natürlichsprachlich oder in Pseudocode angeführt werden, um die durch eine Nachricht ausgelöste Aktivierung näher zu beschreiben. Alle diese Angaben können nicht nur in der Marginalie, sondern alternativ dazu auch unmittelbar neben dem Modellelement angegeben werden, das sie charakterisieren. Abbildung 2 63 zeigt zum Abschluß ein geradezu klassisches Sequenzdiagramm mit beschrifteter Marginalie, das den Aufbau eines Festnetztelefongesprächs modelliert [Rumb91][OMG99][Rumb99].

9 2.5 Kollaborationsdiagramm 117 {b.receivetime - a.sendtime < 1"} {c.receivetime - b.sendtime<10"} The call is routed through the network. {d.receivetime - d.sendtime < 5"} At this point the parties can talk. caller a: lift receiver b: dial tone c: dial digit... d: route ringing tone stop tone exchange phone rings answer phone stop ringing receiver Abb Sequenzdiagramm zum Aufbau eines Telefongesprächs (aus [Rumb99], S. 424 und [OMG99]). Die Verwendung von Alias- Marken wie a, b etc. für Nachrichten als Basis für die Pseudoattribute sendtime und receivetime ist allerdings nicht ganz konform zur textuellen Erläuterung in [OMG99] Kollaborationsdiagramm Ähnlich wie das Sequenzdiagramm zeigt das Kollaborationsdiagramm die für einen bestimmten Zweck notwendigen Interaktionen zwischen Objekten. Beide Diagrammarten werden daher in UML unter dem Oberbegriff Interaktionsdiagramm zusammengefaßt und decken im wesentlichen denselben Einsatzbereich ab. Das Kollaborationsdiagramm ist dem Sequenzdiagramm insofern überlegen, als es zusätzlich zu den Interaktionen auch den ihnen zugrundeliegenden Kontext in Form von Objektbeziehungen darstellt (Kollaboration, vgl. den folgenden Abschnitt). Umgekehrt wird darauf verzichtet, die Zeit als eigene graphische Dimension zu modellieren, sodaß die Reihenfolge von Nachrichten durch Numerieren spezifiziert werden muß. Die einzelnen Unterschiede werden in Abschnitt sowie in Kapitel 5 ab Seite 246 noch genauer diskutiert Kollaboration Eine Kollaboration wird in UML als Ausschnitt aus der statischen Modellstruktur definiert, der genau jene Modellelemente enthält, die zur Erreichung eines definierten Ziels kooperieren. Dabei werden die Modellelemente auf Instanzebene (als Objekte und Objektbeziehungen) dargestellt. Eine Kollaboration repräsentiert also den statischen Kontext eines bestimmten Verhaltens wie etwa eines Anwendungsfalls oder einer Operation, der das Zusammenspiel der benötigten Teilnehmer ermöglicht. Durch Ausblenden von Modellinformation, Kollaborationsdiagramm (collaboration diagram) Wegen der negativ gefärbten Bedeutung des Begriffs»Kollaboration«findet man in der deutschsprachigen UML-Literatur auch andere Übersetzungen, etwa»kooperationsdiagramm«[kahl98]. Die Autoren meinen jedoch, daß es der Vorteil eines minimalen Hamming- Abstands zum Original rechtfertigt, die politische Dimension des Begriffs»Kollaboration«im Kontext von UML zu vernachlässigen.

SEQUENZDIAGRAMM. Christoph Süsens

SEQUENZDIAGRAMM. Christoph Süsens SEQUENZDIAGRAMM Christoph Süsens DEFINITION Das Sequenzdiagramm gibt Auskunft darüber: Welche Methoden für die Kommunikation zwischen ausgewählten Objekten zuständig sind. Wie der zeitliche Ablauf von

Mehr

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte

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

OOA-Dynamische Konzepte

OOA-Dynamische Konzepte Proseminar UML im SS 2005 OOA-Dynamische Konzepte Teil 2 von Benjamin Daeumlich 1 Übersicht Szenario Definition Interaktionsdiagramme Sequenzdiagramm Kommunikationsdiagramm Sequenz- vs. Kommunikationsdiagramm

Mehr

Sequenz- und Kommunikationsdiagrammen. Systemmodellierung mit SysML von Michel Manthey

Sequenz- und Kommunikationsdiagrammen. Systemmodellierung mit SysML von Michel Manthey Sequenz- und Kommunikationsdiagrammen von Michel Manthey 1 Interaktionsdiagramme Sequenzdiagramme (auch in SysML) Kommunikationsdiagramme Zeitdiagramme Interaktionsübersichtsdiagramme von Michel Manthey

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

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

9. Operationenmodellierung mit Interaktionsdiagrammen

9. Operationenmodellierung mit Interaktionsdiagrammen Inhalt 1. Modellierung funktionaler Aspekte im objektorientierten Design 2. Sequenz- und Kollaborationsdiagramme: Notation und Vergleich 3. Beispiele aus dem POS Terminal Beispiel Lernziele: die UML-Notation

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

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

Software Engineering I

Software Engineering I Vorlesung Software Engineering I Dynamische Basiskonzepte 2 Kontrollstrukturen Aktivitätsdiagramme Sequenzdiagramme 1 Basiskonzepte Beschreiben die feste Struktur des Systems, die sich während der Laufzeit

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Unified Modeling Language. Lerneinheit 2. UML - Diagramme. Prof. Dr. D. Frosch-Wilke Prof. Dr. U. Samberg. überarbeitet UML 2.0

Unified Modeling Language. Lerneinheit 2. UML - Diagramme. Prof. Dr. D. Frosch-Wilke Prof. Dr. U. Samberg. überarbeitet UML 2.0 Lerneinheit 2 UML - Diagramme Diagramme in der UML Wesentlicher Bestandteil der Modellbildung Graphen, wobei fundamentale Modellelemente (z.b. Klassen, Objekte, Zustände) die Knoten und Beziehungen zwischen

Mehr

Workflows: Anforderungserhebung und analyse

Workflows: Anforderungserhebung und analyse Workflows: Anforderungserhebung und analyse Tutorium 4 9. März 2009 Svetlana Matiouk, Uni Bonn Ferientutorien zur Vorlesung Softwaretechnologie WS 2008 4. Treffen, Aktivitäten bei der Softwareentwicklung

Mehr

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren

Einführung in die Informationsverarbeitung Teil Thaller. Stunde VII: Planen und Realisieren Einführung in die Informationsverarbeitung Teil Thaller Stunde VII: Planen und Realisieren Manfred Thaller, Universität zu Köln Köln 18. Dezember 2014 Rekapitulation Der Gang der Argumentation 1. Der Rohstoff:

Mehr

Software Engineering Interaktionsdiagramme

Software Engineering Interaktionsdiagramme Software Engineering Interaktionsdiagramme Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Nachrichtenaustausch Welche Nachrichten werden ausgetauscht? (Methodenaufrufe)

Mehr

UML - Tutorial. Hubert Baumgartner. www.inso.tuwien.ac.at

UML - Tutorial. Hubert Baumgartner. www.inso.tuwien.ac.at UML Tutorial UML - Tutorial SS 06 Hubert Baumgartner www.inso.tuwien.ac.at INSO - Industrial Software Institut für Rechnergestützte Automation Fakultät für Informatik Technische Universität Wien Inhalt

Mehr

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Interaktionsdiagramme in UML

Interaktionsdiagramme in UML Interaktionsdiagramme in UML Interaktionsdiagramm ist ein Oberbegriff für eine Reihe von Diagrammen, die das Verhalten eines objektorientierten Systems durch Objektinteraktionen beschreiben Ein Sequenzdiagramm

Mehr

Lösungsvorschlag zu Übungsblatt 1 mit Korrekturhinweisen

Lösungsvorschlag zu Übungsblatt 1 mit Korrekturhinweisen Universität Karlsruhe (TH) Fakultät für Informatik Lehrveranstaltung Informatik II Sommersemester 2008 Prof. Dr. K. Böhm Dipl.-Wirtsch.-Inf. C. Kühne Lösungsvorschlag zu Übungsblatt 1 mit Korrekturhinweisen

Mehr

Softwaretechnik SS 2006

Softwaretechnik SS 2006 Softwaretechnik SS 2006 7. Vorlesungseinheit Prof. Dr. Urs Andelfinger Darmstadt, 22. Mai 2006 Softwaretechnik (SWT) Vorlesung und Praktikum SS 2006 Inhaltsübersicht SW-Management SW-Entwicklung SW-Qualitätsmgmt.

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

Übungsaufgaben UML Zertifizierung Fundamental-Level

Übungsaufgaben UML Zertifizierung Fundamental-Level Übungsaufgaben UML Zertifizierung Fundamental-Level Kapitel 15: Sequenzdiagramm Die folgenden Aufgaben behandeln die Inhalte aus Kapitel 15 von UML 2 glasklar (4. Auflage), die die OMG für die Zertifizierung

Mehr

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 -

Systemanalyse. - Seminar für AI/DM 3 im Wintersemester 2004/05 - Systemanalyse - Seminar für AI/DM 3 im Wintersemester 2004/05 - Prof. Dr. Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule Kaiserslautern,

Mehr

J.2 Objektorientiertes Modellieren mit UML

J.2 Objektorientiertes Modellieren mit UML Modellieren mit UML Objektorientiertes Modellieren mit UML 2002 Prof. Dr. Rainer Manthey Informatik II 1 UML: Übersicht in den 1980er Jahren: Entstehen einer Vielzahl objektorientierter Entwurfsmethoden

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

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

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014

Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme. 11. November 2014 Modellieren mit der Unified Modeling Language: Klassen- und Objektdiagramme 11. November 2014 Überblick Was ist die Unified Modeling Language (UML)? die Standardmodellierungssprache für Softwaresysteme

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

Verfeinerung der Use Case-Dokumentation

Verfeinerung der Use Case-Dokumentation Verfeinerung der Use Case-Dokumentation 4.3 Im ersten Schritt werden in den Use Cases nur die Hauptaufgaben des Systems beschrieben Zur Dokumentation der Use Cases gehört zunächst nur eine grobe kurze

Mehr

Unified Modeling Language (UML )

Unified Modeling Language (UML ) Unified Modeling Language (UML ) Seminar: Programmiersprachenkonzepte Inhalt Einleitung UML 2.0 Diagrammtypen 2 Einleitung Objektorientierte Modellierungssprache Definiert vollständige Semantik Dient der

Mehr

Unternehmensmodellierung

Unternehmensmodellierung Josef L. Staud Unternehmensmodellierung Objektorientierte Theorie und Praxis mit UML 2.0 4ü Springer Inhaltsverzeichnis EINLEITUNG 1 1.1 Unternehmensmodellierung 1 1.2 Objektorientierung als solche 6 1.3

Mehr

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010 Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010 Objektorientierter Softwareentwurf mit UML Grundlagen Neubearbeitung 2010 PGOS2010 I Objektorientierter Softwareentwurf mit UML - Grundlagen

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

12 Anwendungsfalldiagramm

12 Anwendungsfalldiagramm 133 In Abschnitt 1.5 haben Sie gelesen, dass Anwendungssysteme in einen Unternehmenskontext eingebunden sind und dort Geschäftsprozesse unterstützen. Aus diesem Blickwinkel ist die Beschreibung der funktionalen

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

Objektorientierte Analyse (OOA) Inhaltsübersicht

Objektorientierte Analyse (OOA) Inhaltsübersicht Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der

Mehr

Darstellung von Assoziationen

Darstellung von Assoziationen Darstellung von Assoziationen Wie bereit aus Kapitel 1 bekannt, beschreiben Assoziationen Beziehungen zwischen Objekten, die zwischen Klassen modelliert werden. Zunächst soll die Modellierung binärer Assoziationen

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Aufgabe 1 (Anwendungsfalldiagramm)

Aufgabe 1 (Anwendungsfalldiagramm) Studientag in Hagen Kurs 1793 08.07.2012 Aufgabe 1 (Anwendungsfalldiagramm) In dieser Aufgabe soll ein Anwendungsfalldiagramm für die im Folgenden beschriebenen Abläufe bei dem Kauf einer Fahrkarte an

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

OOA.3.1 Funktionsanalyse mit Anwendungsfalldiagrammen (Szenarienanalyse)

OOA.3.1 Funktionsanalyse mit Anwendungsfalldiagrammen (Szenarienanalyse) OOA.3.1 Funktionsanalyse mit Anwendungsfalldiagrammen (Szenarienanalyse) Prof. Dr. rer. nat. habil. Uwe Aßmann Institut für Software- und Multimediatechnik Lehrstuhl Softwaretechnologie Fakultät für Informatik

Mehr

Programmieren in Java

Programmieren in Java FG TECHNISCHE INFORMATIK V JV A00 00 TH 0 Programmieren in Java Anhang A A. Modellierung von OOP-Programmen A.. Klassenkategorien A.2. Klassembeziehungen A.3. Klassendiagramm und Sequenzdiagramm der UML

Mehr

Software Engineering Klassendiagramme weiterführende Konzepte

Software Engineering Klassendiagramme weiterführende Konzepte Software Engineering Klassendiagramme weiterführende Konzepte Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassenattribut: static Implementierung in Java public

Mehr

Übungen zu Modellierung verteilter Systeme

Übungen zu Modellierung verteilter Systeme Technische Universität München SoSe 2014 Institut für Informatik Lösungsblatt 1 PD Dr.habil. B. Schätz Ausgabe: 17. April 2014 M. Gleirscher, D. Marmsoler Besprechung: 24. April 2014 Übungen zu Modellierung

Mehr

Objektorientierte Programmierung. Kapitel 3: Syntaxdiagramme und Grammatikregeln

Objektorientierte Programmierung. Kapitel 3: Syntaxdiagramme und Grammatikregeln Stefan Brass: OOP (Java), 3. Syntaxdiagramme und Grammatikregeln 1/32 Objektorientierte Programmierung Kapitel 3: Syntaxdiagramme und Grammatikregeln Stefan Brass Martin-Luther-Universität Halle-Wittenberg

Mehr

Analyse und Entwurf objektorientierter Systeme

Analyse und Entwurf objektorientierter Systeme Analyse und Entwurf objektorientierter Systeme Teil 3 Modellbildung in der Analysephase 3.1 Statische und dynamische Notationselemente Modul WI111: Objektorientierte Programmierung Fachrichtung Wirtschaftsinformatik

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

UML. Weiteres Vorgehen im Projekt

UML. Weiteres Vorgehen im Projekt UML Download objectif Personal Edition (kostenlos): http://www.microtool.de/objectif/de/download.asp Weiteres Vorgehen im Projekt Komponenten, Klassen, Objekte Prozesse Nichtfunktionale Anforderungen Skizzen,

Mehr

Business Process Model and Notation

Business Process Model and Notation BPMN 2.0 Crashkurs Business Process Model and Notation entwickelt von der Object Management Group, einem Konsortium von vielen Firmen (u.a. HP, IBM, Microsoft, Oracle, SAP) >60 verschiedene Produkte implementieren

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Einführung in UML. Überblick. 1. Was ist UML??? 2. Diagrammtypen. 3. UML Software. Was ist ein Modell??? UML Geschichte,...

Einführung in UML. Überblick. 1. Was ist UML??? 2. Diagrammtypen. 3. UML Software. Was ist ein Modell??? UML Geschichte,... Vorlesung GIS Einführung in UML Stephan Mäs 28. Mai 2009 Überblick 1. Was ist UML??? Was ist ein Modell??? UML Geschichte,... 2. Diagrammtypen Schwerpunkt: Klassendiagramme 3. UML Software Arbeitsgemeinschaft

Mehr

Klassendiagramm. (class diagram)

Klassendiagramm. (class diagram) : Klassendiagramm http:///topic95.html Klassendiagramm (class diagram) Klassendiagramm Objektdiagramm Komponentendiagramm Kompositionsstrukturdiagramm Verteilungsdiagramm Einstieg Paketdiagramm Aufbau

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

Erweiterungen im IMDS-Release 1.8.4

Erweiterungen im IMDS-Release 1.8.4 Erweiterungen im IMDS-Release 1.8.4 Inhaltsverzeichnis 1 EINLEITUNG 2 2 TOYOTA-SPEZIFISCHE ERWEITERUNGEN 2 3 ONLINE REGISTRIERUNG/ANWENDER/ANSPRECHPARTNER 5 4 MDB KAPITEL 2, REZYKLAT-INFORMATION 5 5 LÖSCHEN

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

Objektorientierte Softwareentwicklung

Objektorientierte Softwareentwicklung Objektorientierte Softwareentwicklung Grundkonzepte der UML Die Inhalte der Vorlesung wurden primär auf Basis der angegebenen Literatur erstellt. Darüber hinaus sind viele Teile direkt aus der Vorlesung

Mehr

Sommersemester 2003. Analyse I: Struktur und Verhalten (Szenarien)

Sommersemester 2003. Analyse I: Struktur und Verhalten (Szenarien) Sommersemester 2003 Analyse I: Struktur und Verhalten (Szenarien) 2 Aufgabe 1 Analyse I: Struktur und Szenarien Umfang: 2 Wochen Punkte: 100 P. In diesem ersten Teil der Analyse sollen auf der Basis der

Mehr

Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler

Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungen zur Vorlesung Softwaretechnologie Wintersemester 2009/2010 Dr. Günter Kniesel, Pascal Bihler Übungsblatt 3 Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online

Mehr

3. Tutorium zu Softwaretechnik I

3. Tutorium zu Softwaretechnik I 3. Tutorium zu Softwaretechnik I Aktivitäts-, Sequenz- & Zustandsdiagramme Michael Hoff 20.05.2014 INSTITUT FÜR PROGRAMMSTRUKTUREN UND DATENORGANISATION KIT Universität des Landes Baden-Württemberg und

Mehr

Kontrollstrukturen - Universität Köln

Kontrollstrukturen - Universität Köln Kontrollstrukturen - Universität Köln Mario Manno Kontrollstrukturen - Universität Köln p. 1 Was sind Sprachen Auszeichnungssprachen HTML, XML Programmiersprachen ASM, Basic, C, C++, Haskell, Java, Pascal,

Mehr

(BABOK-v3-Technik 10.42)

(BABOK-v3-Technik 10.42) (BABOK-v3-Technik 10.42) Allgemeines Sequenzdiagramme geben Antworten auf die Frage Wie läuft die Kommunikation in meinem System ab?. Sie ermöglichen die Modellierung von festen Reihenfolgen, zeitlichen

Mehr

EINFÜHRUNG 06.06.2013 IOZ AG 1

EINFÜHRUNG 06.06.2013 IOZ AG 1 BPMN BPMN2.0 EINFÜHRUNG 06.06.2013 IOZ AG 1 EINFÜHRUNG GESCHÄFTSPROZESSMODELLIERUNG Was ist Geschäftsprozessmodellierung? Darstellung von geschäftlichen Abläufen und deren Interaktion Was wird inhaltlich

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

Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30)

Kapitel 4: Dynamische Analyse mit FUSION. SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30) Kapitel 4: Dynamische Analyse mit FUSION SoPra 2008 Kap. 4: Dynamische Analyse mit FUSION (1/30) Dokumente der dynamischen Analyse Analyse des Systemverhaltens (dynamischer Aspekt). Zu entwickeln sind:

Mehr

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

Softwaretechnologie -Wintersemester 2011/2012 - Dr. Günter Kniesel Übungen zur Vorlesung Softwaretechnologie -Wintersemester 2011/2012 - Dr. Günter Kniesel Übungsblatt 3 - Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online-Videothek

Mehr

Software-Engineering

Software-Engineering FH Wedel Prof. Dr. Sebastian Iwanowski SWE43 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 4: Systemanalyse Teil 3: Der Systemanalysestandard UML FH Wedel Prof. Dr. Sebastian Iwanowski

Mehr

Grundlagen der Softwaretechnik

Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

UML 2.0 Das umfassende Handbuch

UML 2.0 Das umfassende Handbuch Christoph Kecher V.-M \MM UML 2.0 Das umfassende Handbuch Galileo Computing Inhalt Vorwort 11 1 Einführung 13 1.1 Weshalb muss Software modelliert werden? 13 1.2 Was ist die UML? 15 1.3 Die Geschichte

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

Von der Idee zum Anforderungsmodell ohne Medienbruch

Von der Idee zum Anforderungsmodell ohne Medienbruch Von der Idee zum Anforderungsmodell ohne Medienbruch Dustin Wüest, Norbert Seyff, Martin Glinz GI-Fachgruppentreffen RE / 30.11.12 Requirements Engineering Research Group Übersicht Problembeschreibung

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

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

Specifying Patterns for Dynamic Pattern Instance Recognition with UML 2.0 Sequence Diagrams. Lothar Wendehals. Universität Paderborn

Specifying Patterns for Dynamic Pattern Instance Recognition with UML 2.0 Sequence Diagrams. Lothar Wendehals. Universität Paderborn Specifying Patterns for Dynamic Pattern Instance Recognition with UML 2.0 Sequence Diagrams Lothar Wendehals 6. Workshop Software-Reengineering Bad Honnef, 3. - 5. Mai 2004 Motivation Unterstützung des

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

(BABOK-v3-Technik 10.47)

(BABOK-v3-Technik 10.47) (BABOK-v3-Technik 10.47) Allgemeines Use-Cases geben Antworten auf die Frage Was soll das geplante System leisten? Diese Frage sollte generell zu Beginn jeder Systementwicklung stehen. Use-Cases genauer

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

teamspace TM Outlook Synchronisation

teamspace TM Outlook Synchronisation teamspace TM Outlook Synchronisation Benutzerhandbuch teamsync Version 1.4 Stand Dezember 2005 * teamspace ist ein eingetragenes Markenzeichen der 5 POINT AG ** Microsoft Outlook ist ein eingetragenes

Mehr

Software Engineering in der Praxis

Software Engineering in der Praxis Software Engineering in der Praxis Praktische Übungen Meitner, Spisländer FAU Erlangen-Nürnberg Objektorientiertes Design 1 / 16 Objektorientiertes Design Matthias Meitner Marc Spisländer Lehrstuhl für

Mehr

Objektorientierte Programmiersprachen

Objektorientierte Programmiersprachen Objektorientierte Programmiersprachen 1960 Algol 1970 Simula Pascal 1980 Smalltalk C Ada 1990 C++ Eiffel Eine ovale Box symbolisiert eine objektorientierte Programmiersprache. Eine rechteckige Box steht

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

Geschäftsabläufe und Beziehungen zwischen. (Mitarbeitende / Geschäftsobjekte)

Geschäftsabläufe und Beziehungen zwischen. (Mitarbeitende / Geschäftsobjekte) BusinessModel Geschäftsabläufe und Beziehungen zwischen Mitarbeitenden und Geschäftsobjekten: Arbeitsabläufe, Mitarbeitende, Hilfsmittel und Organisationsstruktur. Was läuft manuell, was IT-gestützt, wer

Mehr

6.2 Petri-Netze. kommunizierenden Prozessen in der Realität oder in Rechnern Verhalten von Hardware-Komponenten Geschäftsabläufe Spielpläne

6.2 Petri-Netze. kommunizierenden Prozessen in der Realität oder in Rechnern Verhalten von Hardware-Komponenten Geschäftsabläufe Spielpläne 6.2 Petri-Netze WS 06/07 mod 621 Petri-Netz (auch Stellen-/Transitions-Netz): Formaler Kalkül zur Modellierung von Abläufen mit nebenläufigen Prozessen und kausalen Beziehungen Basiert auf bipartiten gerichteten

Mehr

Obligatorische Literatur. Überblick Teil III: Objektorientierte Analyse (OOA) 35.1 Anwendungsfalldiagramme

Obligatorische Literatur. Überblick Teil III: Objektorientierte Analyse (OOA) 35.1 Anwendungsfalldiagramme 35 Szenarienanalyse mit Anwendungsfalldiagrammen (Querschneidende dyn. Modellierung) Obligatorische Literatur Zuser, Kap. 7-9, insbes. 7.3+7.5 Störrle Kap 9, Kap 12 Prof. Dr. rer. nat. Uwe Aßmann Institut

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

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

SmartLines Handbuch. E-Mail: support@activtrades.com Live-Chat: www.activtrades.com Telefon: +49 (0)69 2547 2476 Fax: +44 (0)207 680 7301

SmartLines Handbuch. E-Mail: support@activtrades.com Live-Chat: www.activtrades.com Telefon: +49 (0)69 2547 2476 Fax: +44 (0)207 680 7301 SmartLines Handbuch E-Mail: support@activtrades.com Live-Chat: www.activtrades.com Telefon: +49 (0)69 2547 2476 Fax: +44 (0)207 680 7301 1 Übersicht Verwenden Sie Chart-Trendlines, um Ihrem Handel neue

Mehr

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8 Prof. Dr. Wilhelm Schäfer Paderborn, 8. Dezember 2014 Christian Brenner Tristan Wittgen Besprechung der Aufgaben: 15. - 18. Dezember 2014 Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung

Mehr

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012

Software Engineering 5. UML. Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering 5. UML Franz-Josef Elmer, Universität Basel, HS 2012 Software Engineering: 5. UML 2 Unified Modeling Language (UML) Standardisierte grafische Notationen um Strukturen und Abläufe eines

Mehr

2. Übung zu Software Engineering

2. Übung zu Software Engineering 2. Übung zu Software Engineering WS 2009/2010 Henning Heitkötter Projektplanung, Netzplantechnik AUFGABE 3 1 Aufgabenstellung Ausgangspunkt ist die Anforderungsermittlung, an die sich eine Durchführbarkeitsstudie

Mehr

Codierungstheorie Rudolf Scharlau, SoSe 2006 9

Codierungstheorie Rudolf Scharlau, SoSe 2006 9 Codierungstheorie Rudolf Scharlau, SoSe 2006 9 2 Optimale Codes Optimalität bezieht sich auf eine gegebene Quelle, d.h. eine Wahrscheinlichkeitsverteilung auf den Symbolen s 1,..., s q des Quellalphabets

Mehr

Objektorientierte Geschäftsprozessmodellierung mit der UML

Objektorientierte Geschäftsprozessmodellierung mit der UML Bernd bestereich Christian Weiss Claudia Schröder Tim Weilkiens Alexander Lenhard 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com

Mehr

Version 8.0 Brainloop Secure Dataroom Artikel Serie - Folge 3

Version 8.0 Brainloop Secure Dataroom Artikel Serie - Folge 3 Version 8.0 kommt in Kürze! Was ändert sich? Lesen Sie Folge 3 unserer Serie: Zusammenarbeit im Datenraum Lesen Sie in der dritten Folge unserer Artikel-Serie, wie Sie effizient über den Datenraum mit

Mehr

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla

Klassendiagramm. Kurzer Überblick über UML - Stand 2006. BlaBla BlaBla Diese Kennzeichnungen sind nur Erläuterungen und nicht Bestandteil des Diagramms Quelle: P.Grässle, H.Baumann, P.Baumann, UML projektorientiert, Galileo Verlag, 2003 21 Primäre Begriffe Kapselung

Mehr

Übersicht der UML Diagramme

Übersicht der UML Diagramme Dieser Fachbeitrag ist ein Service der InfraSoft Profis für Ihre professionelle Softwareentwicklung. Übersicht der UML Diagramme Die Unified Modeling Language (UML) ist eine Sprache zur Beschreibung von

Mehr

1. Erläutere ausführlich, welche Beziehung zwischen den Klassen bzw. Interfaces

1. Erläutere ausführlich, welche Beziehung zwischen den Klassen bzw. Interfaces UML Klassen Diagramm Aufgaben UML Klassendiagramm 1. Erläutere ausführlich, welche Beziehung zwischen den Klassen bzw. Interfaces AdressbuchGui und JFrame, AdressbuchGui und AdressbuchGuiListener AdressbuchGuiListener

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Softwaretechnologie -Wintersemester 2013/2014 - Dr. Günter Kniesel

Softwaretechnologie -Wintersemester 2013/2014 - Dr. Günter Kniesel Übungen zur Vorlesung Softwaretechnologie -Wintersemester 2013/2014 - Dr. Günter Kniesel Übungsblatt 3 - Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online-Videothek

Mehr