Vorlesung Software Engineering I

Präsentation zum Thema: "Vorlesung Software Engineering I"—  Präsentation transkript:

1 Vorlesung Software Engineering I
Einführung UML Verhaltensidagramme Strukturdiagramme Design Pattern Dynamische Basiskonzepte 2 Kontrollstrukturen, Aktivitätsdiagramme, Prozessdiagramme Software Engineering I VE 04: Einführung UML Version

2 Systemsichten und Modellierung
Statik Funktionen Daten Datenstrukturen Architektur Dynamik Kontrollstrukturen Zustände Prozesse Zeitliches Verhalten Logik Abhängigkeiten Entscheidungstabellen Mathematik Regeln Beschreiben die feste Struktur des Systems, die sich während der Laufzeit nicht ändert. Beschreiben das Verhalten und die Veränderungen während der Laufzeit. Beschreiben die Programmfunktion logisch und mathematisch Software Engineering I VE 04: Einführung UML Version

3 Unified Modelling Language (UML)
UML = Sprache zur Beschreibung von Softwaresystemen Grundgedanke: Einheitliche Modellierungs-Notation für alle Softwaresysteme UML entstand aus mehreren bestehenden Notationen UML ist eine Notation, keine Methode ! UML ist ein Werkzeug für Systemanalyse und Systemdesign Unterstützung durch viele CASE-Tools Verschiedene Diagrammtypen, die sich gegenseitig ergänzen können und verschiedene Systemaspekte hervorheben UML (Unified Modeling Language) ist ein Standard der OMG ( und ist keine Methode, sondern definiert eine Notation und Semantik zur Visualisierung, Konstruktion und Dokumentation von Modellen für die Geschäftsprozessmodellierung und für die objektorientierte Softwareentwicklung. MDA (Model Driven Architecture) ist ebenfalls ein Standard der OMG ( und definiert eine Vorgehensweise beim Softwareentwicklungsprozess unter Verwendung von UML. MDA unterscheidet zwischen PIM (Platform Independend Model), PSM (Platform Specific Model) und Code und bietet eine Grundlage für automatische Code-Generierung. Software Engineering I VE 04: Einführung UML 3 Version

4 Software Engineering I
Geschichte der UML Personen erwähnen: 1994 Grady Booch und James Rumbaugh bei Rational Software mit dem Ziel einen Industriestandard für die Objektmodellierung zu entwickeln 1995 Unified Method 0.8 als Vorgänger UML 1995 Ivar Jacobson zu Rational Software 1996 UML 0.91 1997 UML1.1 wird als Standard von der Object Management Group (OMG) verabschiedet Inhaltliche Schwerpunkte: OMT: Design Booch: Analyse OOSE: Anforderungen, Prozeß SARA: Architektur Harel: Verhalten Software Engineering I VE 04: Einführung UML Version

5 Software Engineering I
UML2: Diagrammarten sieben Strukturdiagramme sieben Verhaltensdiagramme  UML Diagrammübersicht siehe Software Engineering I VE 04: Einführung UML Version

6 UML2: Verhaltensdiagramme
Anwendungsfalldiagramm (Use Case Diagram) (stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar) Aktivitätsdiagramm (Activity Diagram) (beschreibt Abläufe, die aus einzelnen Aktivitäten bestehen) Zustandsdiagramm (Statechart Diagram) (beschreibt endliche Zustandsautomaten für ein Objekt oder System) Sequenzdiagramm (Sequence Diagram) (beschreibt den zeitlichen Ablauf von Nachrichten zwischen Objekten) Kommunikationsdiagramm (Communication Diagram, ehem. Kollaborationsdiagramm) (Interaktionsdiagramm, zeigt Beziehungen und Interaktionen zwischen Objekten) Zeitverlaufsdiagramm (Timing Diagram) (Interaktionsdiagramm mit Zeitverlaufskurven von Zuständen) Interaktionsübersichtsdiagramm (Interaction Overview Diagram) (Interaktionsdiagramm zur Übersicht über Abfolgen von Interaktionen, ähnlich Aktivitätsdiagramm) Software Engineering I VE 04: Einführung UML Version

7 Software Engineering I
Use-Case-Diagramme Beschreiben das Zusammenwirken von Aktoren [bspw. Personen] mit einem System Use-Case-Diagramme sind Verhaltensdiagramme: Sie beschreiben bestimmte Aspekte, wie sich ein System verhält. Im Use-Case-Diagramm können wesentliche Funktionen des Systems hervorgehoben und zueinander in Beziehung gesetzt werden. Diesen Diagrammen fehlt jedoch eine Möglichkeit, die Reihenfolge der Ausführung festzulegen. Use-Case-Diagramme sind Verhaltensdiagramme: Sie beschreiben bestimmte Aspekte, wie sich ein System verhält. Im Use-Case-Diagramm können wesentliche Funktionen des Systems hervorgehoben und zueinander in Beziehung gesetzt werden. Diesen Diagrammen fehlt jedoch eine Möglichkeit, die Reihenfolge der Ausführung festzulegen. Software Engineering I VE 04: Einführung UML Version

8 Use Case Diagramm: Notation
Akteur Software Engineering I VE 04: Einführung UML Version

9 Use Case Diagramm: Notation
Software Engineering I VE 04: Einführung UML Version

10 Software Engineering I
UML2: Aktionen In UML2 sind die Spracheinheit Aktionen (engl. actions) elementare Bausteine zur Verhaltensmodellierung. Ein- und Ausgabewerte werden über sog. Eingabepins entgegengenommen an sog. Ausgabepins ausgegeben. Software Engineering I VE 04: Einführung UML Version

11 UML2: Spezielle Aktionen
Die UML2 definiert einen Satz von elementaren Aktionen und teilt diese in mehrere Gruppen ein. Im folgenden eine Auswahl: Software Engineering I VE 04: Einführung UML Version

12 Software Engineering I
UML2: Aktivität Eine Aktivität ordnet Aktionen als elementare Verhaltensbausteine in einem Netzwerk an, das aus Knoten und Kanten besteht. Aktivitätskanten sind in zwei Hauptgruppen eingeteilt: ein Kontrollfluss ist eine Aktivitätskante, über die keine Objekt-Token fließen ein Objektfluss ist eine Aktivitätskante, über die Objekt-Token von einem Objektknoten zum nächsten fließen können Eine Aktivität ist ein Zustand mit interner Aktion, die zu einem oder mehreren Zustandsübergängen führt, die automatisch der Beendigung der internen Aktion folgen. Software Engineering I VE 04: Einführung UML Version

13 UML2: Aktivitätsdiagramm (Flussnotation)
Das UML-Äquivalent zum Flussdiagramm Beispiel: Das Aktivitätsdiagramm der UML ist ein Hilfsmittel, um Abläufe schrittweise und übersichtlich darzustellen. Ein Aktivitätsdiagramm kennt grundsätzlich zwei Arten von Bausteinen: Knoten und Kanten. Knoten sind die Stellen, an denen etwas passiert. Kanten sind einfach nur die Verbindungslinien zwischen Knoten. Über diese Verbindungslinien wandern sogenannte Token. Alle Aktionen in einem Aktivitätsdiagramm beschreiben gemeinsam eine Aktivität. Das kann zum Beispiel ein Use-Case sein, aber auch eine in einer Programmiersprache zu entwickelnde Funktion. Der Einsatz von Aktivitätsdiagrammen ist nicht auf die Darstellung von Zusammenhängen von Anforderungen beschränkt, sondern kann während des gesamten Softwareentwicklungsprozesses hilfreich sein. Aktivitätsdiagramme sind die Allround-Diagramme der UML, die immer dann eingesetzt werden können, wenn Abläufe übersichtlich dargestellt werden müssen. Sie werden auch zur Geschäftsprozessmodellierung verwendet. Software Engineering I VE 04: Einführung UML Version

14 UML2: Aktivitätsdiagramm (Knoten-Notation)
Zur Darstellung von Kontrollstrukturen ähnlich wie Struktogramme Unterstützt strukturierte Programmierung besser als Fluss-Notation Software Engineering I VE 04: Einführung UML Version

15 UML2: Aktivitätsdiagramm: Notation
[Bedingung] Kontrollfluß Aktivität2 wird nach Abschluß von Aktivität1 gestartet. Verzweigunsaktivität (kann auch durch normale Aktivität dargestellt werden) Kontrollfluß, der unter der angegebenen Bedingung gewählt wird. Synchronisation der Kontrolle (AND) mit Synchronisationsbedingung (Die Bedingung ist optional.) Aufsplitten der Kontrolle (Zulassen von Parallelität) Software Engineering I VE 04: Einführung UML Version

16 UML2: Aktivitätsdiagramm: Notation
Objekt [Zustand] Klasse Die Ausführung der Aktivität versetzt das Objekt in den angegebenen Zustand (optionales, selten verwendetes Konstrukt in Aktivitätsdiagrammen).  Überlappung zu Zustandsdiagrammen ! Beispiel: aus dem Aktivitätsdiagramm wird eine Bestellung in den Zustand „abgewiesen“ versetzt (was bedeutet das,für das Zustandsdiagramm?) Aktivität wird durchgeführt, wenn über einen der eingehenden Kontrollflüsse die Kontrolle ankommt (OR) Start des Ablaufs und Identifikation der betroffenen Klasse Ende des Ablaufs (optional) Software Engineering I VE 04: Einführung UML Version

17 UML2: Aktivitätsdiagramm
Veränderungen gegenüber der UML1: In der UML1 waren die Aktivitätsdiagramme eine spezielle Form der Zustandsdiagramme. In der UML2 sind die Aktivitätsdiagramme eigenständig. Einige Begriffe der UML1 wurden weiterverwendet, bekamen aber eine vollständig neue Bedeutung. Ein Aktivitätsdiagramm in UML2 beschreibt eine Aktivität, die Teilschritte werden Aktionen genannt. In der UML1 wurden die Teilschritte eines Aktivitätsdiagramms Aktivitäten genannt; die Aktivitäten der UML1 heißen jetzt Aktionen, das Aktivitätsdiagramm von UML1 heißt jetzt Aktivität. Aktivitätsmodelle haben jetzt eine starke Ähnlichkeit zu Petrinetzen. Ein Aktivitätsdiagramm darf mehrere Anfangszustände haben. Signale, Zeitereignis und das Ablaufende wurden als neue Notationselemente eingeführt. Aktivitätsdiagramme dürfen Ein- und Ausgabeparameter enthalten. Aktivitätsdiagramm (activity diagram) 􀂋 Stellt eine Variante eines Zustandsautomaten dar 􀂋 Sind nicht einzelnen Klassen zugeordnet 􀂋 Vergleichbar mit den »alten« Flussdiagrammen bzw. Programmablaufplänen (PAPs) 􀂋 Ein Aktions-Zustand wird verlassen, wenn die mit ihm verbundene Verarbeitung beendet ist (implizites Ereignis) 􀂋 Zustandsübergänge können Wächter (guard conditions) beinhalten, mit denen die Verzweigung des Kontrollflusses beschrieben wird 􀂋 Weder in einem Aktions-Zustand noch bei einem Zustandsübergang sollen explizite Ereignisse vorkommen. Software Engineering I VE 04: Einführung UML Version

18 Beispiel Geschäftsprozessmodellierung
Mit BPMN gibt es auch eine UML-Erweiterung für Geschäftsprozesse: Software Engineering I VE 04: Einführung UML Version

19 Aktivitätsdiagramme (Bewertung)
Ein Aktivitätsdiagramm beschreibt die Reihenfolge und Abhängigkeiten von logisch zusammengehörenden Aktionen. Die Aktionen eines Aktivitätsdiagramms sind Objekten zugeordnet (Unterschied zur Funktionsorientierung von Datenflußdiagrammen !) Geeignet für die Modellierung von Geschäftsprozessen über die Grenzen von Anwendungsfällen hinweg. geeignet für die detaillierte Analyse von Anwendungsfällen. geeignet für die Modellierung von parallelen Software-Systemen mittels Partitionierung (sog. „Swimlanes“) nicht geeignet für die Beschreibung der Interaktion von Objekten nicht geeignet für die Zustandsübergänge eines einzelnen Objektes Software Engineering I VE 04: Einführung UML Version

20 UML: Interaktionsdiagramme
Beschreiben zeitliche Abläufe (Aufrufsequenzen) zwischen (bekannten) Objekten Zwei semantisch äquivalente Darstellungen: (Andere Darstellung, aber dieselbe Sicht) Sequenzdiagramm - Verwendung bei wenigen Klassen - Zeitablauf klar ersichtlich - Basierend auf den Message Sequence Charts (MSCs) der ITU-T Kommunikationsdiagramm - Verwendung bei wenigen Nachrichten - Zeitablauf weniger klar ersichtlich Software Engineering I VE 04: Einführung UML Version

21 Sequenzdiagramm: Notation
ZEIT Das Sequenzdiagramm (engl. sequence diagram) ist ein UML-Diagramm zur Darstellung des zeitlich geordneten Informationsaustausch zwischen Objekten. Dazu werden alle Objekte (Achtung: nicht Klassen!) die miteinander kommunizieren sollen in einer Reihe aufgereiht. Jedes Objekt hat eine eigene Lebenslinie die von oben nach unten verläuft: ist sie dick, so ist das Objekt aktiv, ist sie dünn so ist das Objekt inaktiv. Pfeile deuten Nachrichten an, die von der Lebenslinie eines Objekts zu einem anderen Lebenslinie eines Objekt verläuft. Die Zeitachse läuft dabei von oben nach unten. Sequenzdiagramme der UML2 sind nahe verwandt mit Message Sequence Charts (MSC), einem Standard der ITU-T (International Telecommunication Union - Telecommunication Standardization Sector). Ein Sequenzdiagramm stellt in der Regel einen Weg durch einen Entscheidungsbaum innerhalb eines Systemablaufes dar. Sollen Übersichten mit allen Entscheidungsmöglichkeiten entwickelt werden, so müsste hierzu für jeden möglichen Ablauf ein eigenständiges Sequenzdiagramm modelliert werden; deshalb eignet sich hierfür eher das Aktivitätsdiagramm oder Zustandsdiagramm. Software Engineering I VE 04: Einführung UML Version

22 Sequenzdiagramm: Notation
Software Engineering I VE 04: Einführung UML Version

23 Kommunikationsdiagramm: Notation
Software Engineering I VE 04: Einführung UML Version

24 Kommunikationsdiagramm: Beispiel
Pfandmaschine FlaschenMechanik 1: nimmEineFlasche() 2: [Genommen==TRUE] habeFlasche() Nachricht Objekt Sequenznummer Software Engineering I VE 04: Einführung UML Version

25 Kommunikationsdiagramm: Bewertung
Vorteile: Darstellung von sowohl dynamischen als auch statischen Beziehungen zwischen Objekten. Darstellung komplexer Strukturen und Abläufe möglich. Nachteile: Zeitlicher Verlauf ist weniger übersichtlich. Software Engineering I VE 04: Einführung UML Version

26 Kommunikations- vs. Sequenzdiagramm
Beide Diagramme modellieren denselben Sachverhalt ! Software Engineering I VE 04: Einführung UML Version

27 UML: Strukturdiagramme
Klassendiagramm (Class Diagram) (wichtigstes Diagramm: Klassen und ihre Beziehungen untereinander) Paketdiagramm (Package Diagram) (Gliedert Softwaresysteme in Untereinheiten) Objektdiagramm (Object Diagram) (Objekte, Assoziationen und Attributwerte während Laufzeit) Kompositionsstrukturdiagramm (Composite Structure Diagram) (Abbildung innerer Zusammenhänge einer komplexen Systemarchitektur, Darstellung von Design Patterns) Komponentendiagramm (Component Diagram) (Komponenten und ihre Beziehungen und Schnittstellen) Verteilungsdiagramm (Deployment Diagram) (Einsatzdiagramm, Knotendiagramm, Laufzeitumfeld) Profildiagramm (Profile Diagram) Seit UML 2.2, um eigendefinierte Stereotypen-Sammlungen strukturieren zu können. Software Engineering I VE 04: Einführung UML Version

28 Software Engineering I
Klasse  Objekt Konto Kontonummer: 1009 Inhaber: Helga Schmitt Kontostand: 1.340,- EUR Abheben 300,- EUR Konto Kontonummer: 1007 Inhaber: Emil Braun Kontostand: 560,60 EUR Kontostand abfragen => 560,60 EUR Einzahlen 200,- EUR Kontomodell Konto Kontonummer Inhaber Kontostand Einzahlen Abheben Kontostand abfragen Attribute Methoden Software Engineering I VE 04: Einführung UML Version

29 Software Engineering I
Klassendiagramm: Notation + für public # für protected ~ für package − für private Abstrakt: kursiv geschriebener Klassennamen. Oder „{abstract} Klassenname“. Notationsbeispiel: Software Engineering I VE 04: Einführung UML Version

30 Software Engineering I
Klassendiagramm: Notation Klasse1 erbt von Klasse2 (Klasse1 spezialisiert Klasse2)‏ Beziehung zwischen Klasse 1 und Klasse 2 Gerichtete Assoziation Navigierbar: von Klasse 1 nach 2 nicht navigierbar: von Klasse 2 nach 1 Beziehung zwischen Klasse 1 und Klasse 2 Software Engineering I VE 04: Einführung UML Version

31 Software Engineering I
Klassendiagramm: Notation Klasse1 realisiert Klasse2 Aggregation: Teil des Ganzen. Der Teil kann aber auch alleine bestehen. Komposition: „Existenzabhängiges Teil“ kann nur in Verbindung mit dem Ganzen existieren. Software Engineering I VE 04: Einführung UML Version

32 Software Engineering I
Objektdiagramm: Notation Das Objektdiagramm soll verdeutlichen, wie die Attribute einer Klasse zu einem bestimmten Zeitpunkt (Momentaufnahme) des Programms sind. => Es werden die Ausprägungen einer Klasse dargestellt Software Engineering I VE 04: Einführung UML Version

33 Software Engineering I
Objektdiagramm: Notation Die Komponenten (Assoziationen, Vererbungspfeile, usw.) sind genau gleich wie beim Klassendiagramm. Unterschiede zum Klassendiagramm: Es werden nur die Attribute mit ihren Werten eingetragen (nicht die Methoden)‏ Statt dem Klassennamen wird das Objekt folgendermaßen bezeichnet: Objektname:Klassenname (Wichtig: Unterstreichen nicht vergessen! Mit Unterstreichen wird deutlich gemacht, dass es sich um Objekte handelt. Dies gilt für alle UML-Diagramme)‏ Bei unbekanntem Objektnamen: :Klassenname Datentypen können fortgelassen werden! Software Engineering I VE 04: Einführung UML Version

34 UML: Komponentendiagramm
Komponentensymbol Eine Komponente ist eine austauschbare Einheit Diese Einheit ist ausführbar Komponenten bieten Schnittstellen Komponenten nutzen Schnittstellen anderer Komponenten Software Engineering I VE 04: Einführung UML Version

35 UML: Komponentendiagramm
Komponenten enthalten z.B.: Klassen Pakete Komponenten Verschiedene Darstellungsweisen: Software Engineering I VE 04: Einführung UML Version

36 UML: Komponentendiagramm
Software Engineering I VE 04: Einführung UML Version

37 Implementierungsdiagramme
Zur Darstellung von Aspekten der Implementierung. Dies betrifft sowohl die statische Code-Struktur als auch die Systemstruktur zur Ausführungszeit (Runtime). Speziell bei verteilten Anwendungen und Komponenten ist dies von besonderer Bedeutung. Die UML sieht zwei Implementierungsdiagramme vor: Komponentendiagramm Komponentendiagramme zeigen den Aufbau des Applikationscodes Verteilungsdiagramm Verteilungsdiagramme zeigen die Struktur des Laufzeitsystems, (Physische Struktur) Software Engineering I VE 04: Einführung UML Version

38 UML:Komponentendiagramm
Software Engineering I VE 04: Einführung UML Version

39 UML: Verteilungsdiagramm
Software Engineering I VE 04: Einführung UML Version

40 Bsp. Verteilungsdiagramm
Kommunikation Knoten Software Engineering I VE 04: Einführung UML Version

41 Übung UML Design Pattern
Praxisprojekt Erstellen Sie für Ihre Systemmodellierung ein Design Pattern in UML Benutzen Sie dazu ein CASE-Tool Starten sie mit einem Use-Case-Diagramm Fügen sie jedem Use-Case ein Aktivitätsdiagramm hinzu Modellieren Sie die Systemarchitektur mit einem Component/Deployment Diagram Fügen Sie jeder Komponente ein State Diagramm hinzu etc. Software Engineering I VE 04: Einführung UML Version