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.

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

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

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

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

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 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

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

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

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

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

Objektorientierte Software-Entwicklung

Objektorientierte Software-Entwicklung Objektorientierte Software-Entwicklung Priv.- Doz Dr. Rolf Hennicker 04.10.2002 Kapitel 3 Objektorientierte Analyse Kapitel 3 Objektorientierte Analyse 2 Ziele Eine Anwendungsfall-Analyse für ein zu entwickelndes

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

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

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

Business Process Model and Notation BPMN

Business Process Model and Notation BPMN Business Process Model and Notation BPMN BPMN ist ein Standard der Object Management Group OMG zur graphischen Notation von Geschäftsprozessen Aktueller Standard: BPMN 2.0 (http://www.omg.org/spec/bpmn/2.0/)

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

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

Kurzreferenz UML. Autor: Michael Puff. Stand: 2010-05-21. http://www.michael-puff.de mail@michael-puff.de

Kurzreferenz UML. Autor: Michael Puff. Stand: 2010-05-21. http://www.michael-puff.de mail@michael-puff.de Kurzreferenz UML Autor: Michael Puff Stand: 2010-05-21 http://www.michael-puff.de mail@michael-puff.de Inhaltsverzeichnis Inhaltsverzeichnis 1 Die Modellierungssprache UML 5 1.1 Definition Klasse - Objekt......................

Mehr

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim

Software-Design. Definition Der Prozess Prinzipien Strategien und Methoden Notationen. Aufgabe. HS Mannheim Software- Der Strategien und ist der zum Definieren der Architektur, der Komponenten, der Schnittstellen und anderer Charakteristika (Datenstrukturen, Algorithmen etc.) eines Systems oder einer Komponente

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

6 InfoCubes erstellen und konfigurieren

6 InfoCubes erstellen und konfigurieren InfoCubes bilden die Reportingschicht in der LSA; sie sind für die Performance des Reportings entscheidend. In diesem Kapitel stellen wir Ihnen vor, welche InfoCubes es gibt und wie Sie damit arbeiten.

Mehr

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ

Objektorientierte Programmierung. Objektorientierte Programmierung. Klasse. Objekt. Beispiel: Sportfest1. Methode. Eine Einführung mit BlueJ Objektorientierte Programmierung Objektorientierte Programmierung Eine Einführung mit BlueJ stellt die Daten, ihre Struktur und ihre Beziehungen zueinander in den Vordergrund. Weniger im Blickpunkt: die

Mehr

Egon Börger (Pisa) S-BPM. Über den praktischen Gewinn. einer wissenschaftlichen Fundierung

Egon Börger (Pisa) S-BPM. Über den praktischen Gewinn. einer wissenschaftlichen Fundierung Egon Börger (Pisa) S-BPM Über den praktischen Gewinn einer wissenschaftlichen Fundierung Dipartimento di Informatica, Università di Pisa, Pisa (Italia) boerger@di.unipi.it Copyright c Egon Börger, Dipartimento

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

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 Vorname: Name: Matrikelnummer: Prüfungstag: 19.02.2015

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

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

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

1. Grundlegende Konzepte der Informatik

1. Grundlegende Konzepte der Informatik 1. Grundlegende Konzepte der Informatik Inhalt Algorithmen Darstellung von Algorithmen mit Programmablaufplänen Beispiele für Algorithmen Aussagenlogik Zahlensysteme Kodierung Peter Sobe 1 Algorithmen

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

Lars Ebrecht. Echtzeit 2011, GI VDI/VDE, Boppard 04. November 2011

Lars Ebrecht. Echtzeit 2011, GI VDI/VDE, Boppard 04. November 2011 Entwurfsverfahren Das atomare Element als Meta-Modell zur tabellarischen Verhaltensbeschreibung von Echtzeitsystemen Lars Ebrecht Echtzeit 2011, GI VDI/VDE, Boppard 04. November 2011 Echtzeitbetrieb im

Mehr

Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse -

Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse - Systemanalyse und Systemmodellierung - Objekt-orientierte Analyse - Software Engineering 1 WS 2011/2011 Dr. Ina Schaefer Software Systems Engineering Technische Universität Braunschweig (Folien von Prof.

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster

Webseitennavigation mit dem Content-Management-System Imperia. Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster Webseitennavigation mit dem Content-Management-System Imperia Zentrum für Informationsverarbeitung Westfälische Wilhelms-Universität Münster 10. Januar 2006 Inhaltsverzeichnis 1. Einführung 4 2. Rubrikenstruktur

Mehr

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit

1 Hochverfügbarkeit. 1.1 Einführung. 1.2 Network Load Balancing (NLB) Quelle: Microsoft. Hochverfügbarkeit 1 Hochverfügbarkeit Lernziele: Network Load Balancing (NLB) Failover-Servercluster Verwalten der Failover Cluster Rolle Arbeiten mit virtuellen Maschinen Prüfungsanforderungen von Microsoft: Configure

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

Formaler Entwurf mit Event-B Die Eventbank

Formaler Entwurf mit Event-B Die Eventbank Institut für Theoretische Informatik Anwendungsorientierte Formale Verifikation Vorlesung Anwendung Formaler Verifikation SS 2015, 9.6.15 Dr. V. Klebanov, Dr. M. Ulbrich Formaler Entwurf mit Event-B Die

Mehr

Kiwi. Modellkonsistenz. Themenbereich Modellmanagement und Qualität

Kiwi. Modellkonsistenz. Themenbereich Modellmanagement und Qualität Kiwi. Kiwi. Modellkonsistenz Themenbereich Modellmanagement und Qualität Vortrag im Seminar Software-Qualität bei der modellbasierten Softwareentwicklung (SS2007) Stefan Marr Agenda 3 Softwareentwicklung

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

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Die Firma Otto Klein in Hanau ist wegen der Herstellung

Die Firma Otto Klein in Hanau ist wegen der Herstellung OTTO KLEIN & CO. Die Firma Otto Klein in Hanau ist wegen der Herstellung der offiziellen Version des Eichenlaubs mit Schwerter und Diamanten und des extrem seltenen Goldenen Eichenlaubs mit Schwertern

Mehr

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik)

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Prof. Dr. Th. Letschert CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Vorlesung 7 Th Letschert FH Gießen-Friedberg Ressourcen Verwaltung passive Ressourcen aktive Ressourcen

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

Übung zur Vorlesung Einführung in die Computerlinguistik und Sprachtechnologie

Übung zur Vorlesung Einführung in die Computerlinguistik und Sprachtechnologie Übung zur Vorlesung Einführung in die Computerlinguistik und Sprachtechnologie Wintersemester 2009/10, Prof. Dr. Udo Hahn, Erik Fäßler Übungsblatt 3 vom 19.11.2009 Abgabe bis 26.11.2009, 14:30 Uhr; per

Mehr

2. Die Darstellung von Algorithmen

2. Die Darstellung von Algorithmen 2. Die Darstellung von Algorithmen Aus den Einführungsbeispielen und Übungsaufgaben ist erkennbar, dass zur Darstellung von Algorithmen Grundelemente notwendig sind. Neben der Notation einzelner elementarer

Mehr

Geschäftsprozesse: Modellierung und Analyse

Geschäftsprozesse: Modellierung und Analyse Geschäftsprozesse: Modellierung und Analyse 1. Ausgangssituation 2. Begriffe 3. Modellierungsmethoden 4. Modellarten 5. Vorgehensprinzipien 6. Analyse 7. Werkzeuge Begriffe: Methoden, Verfahren, Notationen,...

Mehr

Innovator 11 classix. Projektpläne für MS Project aus Innovator Business classix generieren. connect. Oliver Pera. www.mid.de

Innovator 11 classix. Projektpläne für MS Project aus Innovator Business classix generieren. connect. Oliver Pera. www.mid.de Innovator 11 classix Projektpläne für MS Project aus Innovator Business classix generieren Oliver Pera connect www.mid.de Projektpläne für MS Project aus Innovator Business classix generieren Inhaltsverzeichnis

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

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

VMware Workspace Portal- Benutzerhandbuch

VMware Workspace Portal- Benutzerhandbuch VMware Workspace Portal- Benutzerhandbuch Workspace Portal 2.1 Dieses Dokument unterstützt die aufgeführten Produktversionen sowie alle folgenden Versionen, bis das Dokument durch eine neue Auflage ersetzt

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

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0

Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Was ist Language Based BPM? Eine kurze Erklärung Version 1.0 Dieses Dokument wurde verfasst von Dr. Jürgen Pitschke, BCS-Dr. Jürgen Pitschke, www.enterprise-design.eu Diese Unterlagen können frei für nicht-kommerzielle

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

Sascha Schreier. Softwaretechnik: Übung 11.12.09

Sascha Schreier. Softwaretechnik: Übung 11.12.09 Sascha Schreier Softwaretechnik: Übung 11.12.09 Unklarheiten und Fragen Sascha Schreier 11.12.2009 # 2 Systementwurf: Objektentwurf + Einbettung in die Systemumgebung (Pakete, DB, GUI, ) So viele verschiedene

Mehr

Inhalte der Veranstaltung

Inhalte der Veranstaltung Inhalte der Veranstaltung 5. Anwendungssysteme 5-4 6. Entwurf von Anwendungssystemen 6.1 Datenmodellierung 6-1 6.2 Geschäftsprozessmodellierung 6-32 6.3 Entwurf von Datenbanken 6-79 6.4 Nutzung von Datenbanken

Mehr

Together - Integrierte SWE und QA 1. Flugbuchungssystem

Together - Integrierte SWE und QA 1. Flugbuchungssystem Together - Integrierte SWE und QA 1 Flugbuchungssystem Aufgabe 1: Use Case Diagramm Um die Anforderungen des fiktiven Kunden Airwings zu erfassen, sollen Use Case Diagramme verwendet werden. Im informellen

Mehr

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 3 Dr. H. Ehler, S. Wagner 8. Februar 2007 Übungen zu Softwaretechnik Aufgabe 23 CMM Das Capability Maturity Model (CMM) wurde entwickelt, um die Fähigkeit von Auftragnehmern

Mehr

Model Driven Requirements Engineering im Energiehandel. Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase

Model Driven Requirements Engineering im Energiehandel. Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase Model Driven Requirements Engineering im Energiehandel Am Beispiel der UML basierten Anforderungsverfeinerung und der Metamodell-Klasse UseCase Requirements Engineering ETG-RPI Autor Lars van Brackel V.10

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Ich begrüße Sie zu unserer nächsten Vorlesung aus Objektorientierter Modellierung. Heute geht es um das Zustandsdiagramm.

Ich begrüße Sie zu unserer nächsten Vorlesung aus Objektorientierter Modellierung. Heute geht es um das Zustandsdiagramm. Ich begrüße Sie zu unserer nächsten Vorlesung aus Objektorientierter Modellierung. Heute geht es um das Zustandsdiagramm. Seite 0 Seite 1 Zu Beginn dieser Einheit möchte ich ein kleines Experiment mit

Mehr

VHDL Verhaltensmodellierung

VHDL Verhaltensmodellierung VHDL Verhaltensmodellierung Dr.-Ing. Matthias Sand Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2008/2009 VHDL Verhaltensmodellierung 1/26 2008-10-20

Mehr

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 2-

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 2- Systemanalyse - Folien zur Vorlesung für AI3 im Sommersemester 2010 - -Teil 2- Hans-Jürgen Steffens (by courtesy of Prof. Dr. Thomas Allweyer) Fachbereich Informatik und Mikrosystemtechnik Fachhochschule

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

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

Mehr

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell

Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Lösungen zu Übung 3 Objektorientierte Modellierung - Statisches Modell Aufgabe 3. Assoziation

Mehr

E-Mail-Konto. MS Outlook 2003

E-Mail-Konto. MS Outlook 2003 E-Mail-Konto einrichten unter MS Outlook 2003 Alois Kratochwill Dipl. FW. f.a.inf. projects of WDNS.at office@wdns.at http://www.wdns.at Online-Management für E-Mail-Administratoren http://mxadmin.wdns.at

Mehr

Modellierung einer Android-App. 2. Mai 2013

Modellierung einer Android-App. 2. Mai 2013 Modellierung einer Android-App 2. Mai 2013 Taentzer Software-Praktikum 2013 42 Überblick Modellierung der wesentlichen Aspekte Welche Anwendungsfälle haben wir? Übersicht durch Anwendungsfalldiagramme

Mehr

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung

Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) Vorgehensmodelle für die objektorientierte Systementwicklung Objektorientierte Systementwicklung mit der Unified Modeling Language (UML) (Dr. Markus Nüttgens, Dipl.-Hdl. Michael Hoffmann, Dipl.-Inform. Thomas Feld, Institut für Wirtschaftsinformatik (IWi), Universität

Mehr

Situativer Widerspruch für ELGA in HL7 V2.x: Spezifizierung des CON-Segments

Situativer Widerspruch für ELGA in HL7 V2.x: Spezifizierung des CON-Segments 1 2 Situativer Widerspruch für ELGA in HL7 V2.x: Spezifizierung des CON-Segments 3 4 5 6 Version: Standard des Technischen Komitees der HL7 Austria - Version 1.0 Datum: 13.04.2015 Dokument OID: 2.16.840.1.113883.2.16.1.2.1.20150413.3

Mehr

Seminar Ausgewählte Themen des Software Engineering. Fundamental Modeling Concepts

Seminar Ausgewählte Themen des Software Engineering. Fundamental Modeling Concepts Seminar Ausgewählte Themen des Software Engineering Fundamental Modeling Concepts Wieland Rhenau Freie Universität Berlin, Institut für Informatik WS 2005/2006 Wieland Rhenau, rhenau@inf.fu-berlin.de 1

Mehr

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems Michael Gebhart (1), Jürgen Moßgraber (2), Thomas Usländer (2), Sebastian Abeck (1) (2) (1) Cooperation & Management, Karlsruher Institut

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

OrthoWin ShapeDesigner Software-Anleitung

OrthoWin ShapeDesigner Software-Anleitung OrthoWin ShapeDesigner Software-Anleitung Inhalt ORTHEMA Seite 1 1 Einleitung...3 2 Menüsteuerung...3 3 Hauptfenster...4 4 Datei Menü...5 4.1 Neu und Öffnen...5 4.2 Speichern und Speichern unter...5 4.3

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

Mehr

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN)

Geschäftsprozessmanagement: Einführung in»business Process Modelling Notation«(BPMN) Geschäftsprozessmanagement: in»business Process Modelling Notation«(BPMN) Eugen Labun Fachhochschule Gießen-Friedberg Fachbereich MNI Institut für Softwarearchitektur Serviceorientierte Architekturen bei

Mehr

Solution for Business Intelligence. MID Insight 2013

Solution for Business Intelligence. MID Insight 2013 Solution for Business Intelligence MID Insight 2013 A G E N D A 1. Solution für Business Intelligence (BI) 2. Die Gründe und Hintergründe 3. Die Methode 4. Vorteile MID GmbH 2013 2 Solution für Business

Mehr

Business Process Execution Language. Christian Vollmer Oliver Garbe

Business Process Execution Language. Christian Vollmer <christian.vollmer@udo.edu> Oliver Garbe <oliver.garbe@udo.edu> Business Process Execution Language Christian Vollmer Oliver Garbe Aufbau Was ist BPEL? Wofür ist BPEL gut? Wie funktioniert BPEL? Wie sieht BPEL aus?

Mehr

Bedienung von BlueJ. Klassenanzeige

Bedienung von BlueJ. Klassenanzeige Im Folgenden werden wichtige Funktionen für den Einsatz von BlueJ im Unterricht beschrieben. Hierbei wird auf den Umgang mit Projekten, Klassen und Objekten eingegangen. Abgeschlossen wird dieses Dokument

Mehr

State Event Technik CT2, Donnerstag 10.00-11.35 / TE402 M. Thaler, TG208, tham@zhaw.ch

State Event Technik CT2, Donnerstag 10.00-11.35 / TE402 M. Thaler, TG208, tham@zhaw.ch State Event Modellierung State Event Technik CT2, Donnerstag 10.00-11.35 / TE402 M. Thaler, TG208, tham@zhaw.ch http://www.zhaw.ch/~tham 1 ZHAW, CT2 FS14, M. Thaler Systembus CT2 Anschluss von Input/Output

Mehr

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases

effektiv erstellen Use Cases Alistair Cockburn Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Alistair Cockburn Use Cases effektiv erstellen Das Fundament für gute Software-Entwicklung Geschäftsprozesse modellieren mit Use Cases Die Regeln für Use Cases sicher beherrschen A Abdeckung Grad der 163

Mehr

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Dipl. Inform. Olaf Maibaum DLR, Abt. Simulations- und Softwaretechnik DLR, Abt. Simulations- und Softwaretechnik 1 Übersicht Bird-Satellit

Mehr

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle 1 Das Entity-Relationship-Modell Prof. Dr. Bernhard Schiefer 2-1 Datenbankmodelle ER-Modell hierarchisches Modell Netzwerkmodell relationales Modell objektorientierte Modelle Prof. Dr.

Mehr

Vgl. Oestereich Kap 2.6 Seiten 127-133

Vgl. Oestereich Kap 2.6 Seiten 127-133 Vgl. Oestereich Kap 2.6 Seiten 127-133 4. Zustände 1 Aktivitäts- und Zustands-Diagramm werden oft verwechselt. Es ist darum wichtig zu unterscheiden, dass im Aktivitätsdiagramm die Aktionen im Zentrum

Mehr

Schnittstelle zu Inxmail. Prozess der Verwendung von Inxmail im Kontext von CAS genesisworld

Schnittstelle zu Inxmail. Prozess der Verwendung von Inxmail im Kontext von CAS genesisworld Schnittstelle zu Inxmail Prozess der Verwendung von Inxmail im Kontext von CAS genesisworld Copyright Die hier enthaltenen Angaben und Daten können ohne vorherige Ankündigung geändert werden. Die in den

Mehr

Sprachbeschreibung und Erweiterung

Sprachbeschreibung und Erweiterung Sprachbeschreibung und Erweiterung Worte, Sprachen, reguläre Ausdrücke, Automaten, BNF, Grammatik, Syntax- Diagramme, Spracherweiterungen do, for, break, switch Formale Beschreibung von Programmiersprachen

Mehr

Bedienungsanleitung ComfortTouch App für Busch-ComfortPanel. Busch-ComfortPanel 9 8136/09-811 8136/09-825

Bedienungsanleitung ComfortTouch App für Busch-ComfortPanel. Busch-ComfortPanel 9 8136/09-811 8136/09-825 1373-1-8367 01.08.2013 Bedienungsanleitung Busch- 9 8136/09-811 8136/09-825 Busch- 12.1 8136/12-811 8136/12-825 1 Einleitung... 3 1.1 Bestimmungsgemäßer Gebrauch... 3 2 Systemvoraussetzung der mobilen

Mehr

Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke

Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke Christian Schröder Telelogic Deutschland GmbH Bielefeld http://www www.forsoft.de/.de/automotive/ Christian Schröder VDI

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015

Abstrakt zum Vortrag im Oberseminar. Graphdatenbanken. Gero Kraus HTWK Leipzig 14. Juli 2015 Abstrakt zum Vortrag im Oberseminar Graphdatenbanken Gero Kraus HTWK Leipzig 14. Juli 2015 1 Motivation Zur Darstellung komplexer Beziehungen bzw. Graphen sind sowohl relationale als auch NoSQL-Datenbanken

Mehr

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent Outlook 2003 - Aufbaukurs 19 Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent Wie kann ich die Bearbeitung von Nachrichten automatisieren? Wie kann ich Nachrichten automatisch

Mehr

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny

Grundlagen der Informatik. Prof. Dr. Stefan Enderle NTA Isny Grundlagen der Informatik Prof. Dr. Stefan Enderle NTA Isny 2 Datenstrukturen 2.1 Einführung Syntax: Definition einer formalen Grammatik, um Regeln einer formalen Sprache (Programmiersprache) festzulegen.

Mehr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr

Uni Duisburg-Essen Fachgebiet Informationssysteme Prof. Dr. N. Fuhr Raum: LF 230 Bearbeitung: 25.-29. April 2005 Datum Gruppe Vorbereitung Präsenz Aktuelle Informationen unter: http://www.is.informatik.uni-duisburg.de/courses/dbp_ss03/index.html Datenbankentwurf Der Entwurf

Mehr

Design by Contract zur semantischen Beschreibung von Web Services

Design by Contract zur semantischen Beschreibung von Web Services Design by Contract zur semantischen Beschreibung von Web Services Gregor Engels 1, Marc Lohmann 1, Stefan Sauer 2 1 Institut für Informatik, 2 Software Quality Lab (s-lab) Universität Paderborn, 33095

Mehr

8 Kapitel TypoScript 219

8 Kapitel TypoScript 219 8 Kapitel TypoScript TypoScript gehört zu den umfangreichsten und zugleich wichtigsten Bereichen, die ein TYPO3 Integrator beherrschen muss. Nahezu die gesamte Erstellung einer Website, angefangen bei

Mehr

Das ist neu in UML 2.0. max.kleiner.com

Das ist neu in UML 2.0. max.kleiner.com Das ist neu in UML 2.0 max.kleiner.com Die 2.0 ist formal in 3 Gebiete aufgeteilt: " UML Infrastructure,, Vereinfachung und Modularisierung des Metamodells,, Profiles und Stereotypen. Das D Metamodell

Mehr

Literatur. 3. Erste Schritte in der Objektorientierte Analyse mit CRC-Karten. Die Rolle von Entwurfsmethoden in der Softwareentwicklung.

Literatur. 3. Erste Schritte in der Objektorientierte Analyse mit CRC-Karten. Die Rolle von Entwurfsmethoden in der Softwareentwicklung. 3. Erste Schritte in der Objektorientierte Analyse mit Literatur Obligatorische Literatur Zuser Kap 9 Weiterführende Literatur Scott Ambler. The Object Primer. Cambridge University Press. Gutes Kapitel

Mehr