Software-Engineering II

Slides:



Advertisements
Ähnliche Präsentationen
Business Engineering Philipp Osl, Alexander Schmidt
Advertisements

1 Referenzmodelle für HISinOne Dr. Uwe Hübner, 02. Juli 2009.
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil3.
Rollenbasierter Entwurf am Beispiel eines benutzeradaptierbaren Hyperbooks Institut für Informatik Rechnergestützte Wissensverarbeitung Universität Hannover.
Kritische Betrachtung
Die Definitionsphase -Objektorientierte Analyse - Das statische Modell
Modelle und Methoden der Linearen und Nichtlinearen Optimierung (Ausgewählte Methoden und Fallstudien) U N I V E R S I T Ä T H A M B U R G November 2011.
Das Entity-Relationship-Modell
Objektorientierter Entwurf
WS 04/05 wiss. Übung: Systemanalyse und Softwaredesign
Objektorientierte Konzepte und Notation in UML
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Anwendungsfalldiagramm
Ziel: externe Systemverhalten aus Anwendersicht
Sequenzdiagramm.
Objektorientierte Analyse (OOA) Inhaltsübersicht
Java: Objektorientierte Programmierung
Java: Grundlagen der Objektorientierung
Abhängigkeitsbeziehung
UML im Überblick – Dipl. Ing. Ulrich Borchert / FH Merseburg 1/22
Grundkurs Theoretische Informatik, Folie 2.1 © 2006 G. Vossen,K.-U. Witt Grundkurs Theoretische Informatik Kapitel 2 Gottfried Vossen Kurt-Ulrich Witt.
Vorlesung: 1 Betriebliche Informationssysteme 2003 Prof. Dr. G. Hellberg Studiengang Informatik FHDW Vorlesung: Betriebliche Informationssysteme Teil2.
Modellierung komplexer Realität mit Objekten
Institut für Kartographie und Geoinformation Prof. Dr. Lutz Plümer Diskrete Mathematik I Vorlesung Listen-
Vererbung Spezialisierung von Klassen in JAVA möglich durch
PKJ 2005/1 Stefan Dissmann Rückblick auf 2005 Was zuletzt in 2005 vorgestellt wurde: Klassen mit Attributen, Methoden und Konstruktoren Referenzen auf.
PKJ 2005/1 Stefan Dissmann Zusammenfassung Bisher im Kurs erarbeitete Konzepte(1): Umgang mit einfachen Datentypen Umgang mit Feldern Umgang mit Referenzen.
PKJ 2005/1 Stefan Dissmann Klassenhierarchie Person Kunde Goldkunde Lieferant Object.
1 WS 2012 Software-Engineering II Aspektorientierung.
DVG Klassen und Objekte
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl
UML-Klassendiagramm: Assoziationen (1)
Rational Rose und UML: Erstellung einer Kontoverwaltung
UML Begleitdokumentation des Projekts
Seite 1 Interface - Konzept Ein Interface führt einen neuen Datentyp ein: interface Frau {... } Das Interface enthält Deklarationen ( keine Definitionen.
Visualisierung objektrelationaler Datenbanken
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
12. Vorlesung: Aktivitätsdiagramme
10. Vorlesung: Dynamische Konzepte
20:00.
Sequenzdiagramme (1) Festlegen des Inter-Objekt-Verhaltens (Interaktionsstruktur, Verantwortlichkeiten) Sequenzdiagramm ist temporal orientiert zeigt.
Unified Modeling Language Repetition / Einführung zu UML
Datenbankentwurf Abstraktionsebenen des Datenbankentwurfs
Entwurfs- und Implementationsdiagramme
Institut für Kartographie und Geoinformation Prof. Dr. Lutz Plümer Objektorientierte Konzepte/UML Geoinformation I Vorlesung 2 WS 2000/2001.
UML WS 09/10: Datenbanken vs MarkUp Dozent: Prof. Dr. Manfred Thaller
Javakurs FSS 2012 Lehrstuhl Stuckenschmidt
OOP-Begriffe Abstraktion Modellieren Klasse Objekt Attribute Methoden
Analyse von Ablaufdiagrammen
UML-Kurzüberblick Peter Brusten.
UML Modellierung des Verhaltens von Klassen und Objekten
Paradigmenwechsel in der Unternehmensmodellierung Prof. Dr. Wolfgang Voigt Dipl.-Ing. Päd. Alexander Huwaldt UML Extrakt UML Seminar, Chemnitz
Vom Geschäftsprozess zum Quellcode
Vorlesung Mai 2000 Konstruktion des Voronoi-Diagramms II
Informatik und Programmieren 3
1 (C)2006, Hermann Knoll, HTW Chur, FHO Quadratische Reste Definitionen: Quadratischer Rest Quadratwurzel Anwendungen.
SOFTWARE TECHNOLOGY 2009/2010 Faculty of Electrical Engineering and Technical Informatics Budapest University of Technology and Economics OO problems 1.
Schutzvermerk nach DIN 34 beachten 20/05/14 Seite 1 Grundlagen XSoft Lösung :Logische Grundschaltung IEC-Grundlagen und logische Verknüpfungen.
Objektorientierte Modellierung mit UML
Klassen und Klassenstruktur
1 Medienpädagogischer Forschungsverbund Südwest KIM-Studie 2014 Landesanstalt für Kommunikation Baden-Württemberg (LFK) Landeszentrale für Medien und Kommunikation.
SS 2014 – IBB4C Datenmanagement Do 17:00 – 18:30 R Vorlesung #3 ER Modellierung.
Java-Kurs Übung Besprechung der Hausaufgabe
Sichtbarkeit einschränken
Abstrakte Klassen und das Interface-Konzept
Name des Vortragenden ‌ Klasse ‌‌‌ Ort / tt.mm.jjjj Anwendungsfalldiagramm.
Tutorium Software-Engineering SS14 Florian Manghofer.
A nwendungsfalldiagramm. Ü berblick  Allgemein  Anwendungsfalldiagramm in Stichpunkten  Zusammenhang  Anwendungsbereich  Diagramm.
UML – Unified Modeling Language
 Präsentation transkript:

Software-Engineering II UML

Themenübersicht Objektorientierung Aspektorientierung Vorgehensmodelle UML Analyse- & Entwurfsmuster Objektorientiertes Testen Versionsverwaltung Refactoring Labor (Praktischer Teil)

UML UML 2.0 Christoph Kecher Galileo Computing 424 Seiten ISBN: 3-8984-2738-2 (Deutsch)

UML – Was ist das? Eigenschaften Unified Modelling Language Allgemein verwendbare Modellierungsnotation Im Laufe vieler Jahre entstanden Unabhängig von Programmiersprachen Unabhängig von Vorgehensmodellen Eigenschaften Einfach Verständlich Ausdrucksstark Standardisiert

Diagrammtypen Klassendiagramm Objektdiagramm Paketdiagramm … Strukturdiagramme Klassendiagramm Objektdiagramm Paketdiagramm … Modellieren statische, zeitunabhängige Gegebenheiten Verhaltensdiagramme Use-Case-Diagramm Aktivitäts-Diagramm Zustandsdiagramm Sequenzdiagramm … Modellieren Verhalten und zeitabhängige Gegebenheiten

Use-Case-Diagramm Modellieret Funktionalität des zu entwickelnden Systems Zeitpunkt: Analysephase Bildet Grundlage für weitere Modelle Hohes Abstraktionsniveau Sicht eines externen Anwenders Modelliert, welche Anwendungsfälle die Software bieten wird und nicht wie es Realisiert werden kann

Akteur Modelliert einen Typ oder eine Rolle, die ein externer Benutzer oder ein externes System einnimmt Mehrere Akteure sind möglich

Anwendungsfall Spezifiziert eine Aktion oder eine Menge von Aktionen, die von einem Subsystem zur Verfügung gestellt wird Anwendungsfall Subsystem

Assoziation Modelliert Beziehungen zwischen Anwendungsfällen Wird angewandt, wenn Akteure Anwendungsfälle ausführen dürfen Anmerkung: Da Aktoren externe Elemente in Use-Cases representieren, werden sie außerhalb der Subsystemgrenzen positioniert

Generalisierung Ein Akteur erbt alle Eigenschaften eines anderen Akteurs Kann auch für Anwendungsfälle verwendet werden

Include Modelliert das unbedingte Einbinden eines Anwendungsfalles in einen anderen Jedes Mal, wenn ein Anwendungsfall ausgeführt wird, müssen alle mit <<include>> assoziierten Anwendenfälle ausgeführt werden Im Bsp.: Das Planen einer Vorlesung beinhaltet demnach immer das Vorbereiten des Vorlesungsinhaltes, das Halten der Vorlesung und das Festlegen der Prüfungsleistung

Extends Modelliert das bedingte Einbinden eines Anwendungsfalles in einen Anderen Ein bedingt eingebundener Anwendungsfall kann (muss aber nicht) bei der Ausführung des einbindenden Anwendungsfalles durchgeführt werden Achtung: Der Pfeil zeigt von dem bedingt eingebundenen Anwendungsfall auf den Einbindenden

Extension Points Definieren, welchen Teil eines Anwendungsfalles eine Extends-Beziehung bedingt erweitert Extension Point Extension Point

Aktivitätsdiagramm Fokus auf Aktionen, die durchgeführt werden können Analyse-Phase: Modellierung von Geschäftsprozessen Zeigt Reihenfolge von Prozessen und Tätigkeiten auf Erleichtert Analyse der Geschäftsprozesse Können zur Umsetzung verwendet werden Sicht des Anwenders Entwurfs-Phase Modellierung von internen Systemprozessen Wichtigster Einsatz der AD Umfangreiche Abläufe, komplexe Algorithmen Implementierungs-Phase: Realisierungsvorlage Test-Phase: Grundlage für Testfälle

Aktion Ausführbarer Knoten, der Funktionalität bietet Grundlegende Einheit eines Aktivitätsdiagrammes

Kontrollfluss Gerichtete Verbindung zw. Aktionsknoten Definiert die Reihenfolge der Aktivitäten Kontrollfluss

Aktivitätsbereich Akteur Ordnet Aktivitäten eindeutig Akteuren zu (Siehe Use-Case-Diagramm) Alle Aktionen, die hier modelliert werden, müssen im Use-Case-Diagramm zuvor definiert worden sein Umgekehrt ist es jedoch möglich, dass eine in einem Use-Case-Diagramm definierte Aktion nicht in einem Aktivitätsdiagramm verfeinert wird Akteur

Entscheidungsknoten Modellieren Entscheidungsfälle Startpunkt Endpunkt

Gabelung / Zusammenführung Deutet parellele Abläufe an Gabelung Zusammen- führung

Zustandsdiagramm Ahnlich dem Aktivitätsdiagramm Ähnliche Symbolik Konzentriert sich im Gegensatz zum Aktivitätsdiagramm nicht auf Aktionen sondern (zustandsabhängige) Reaktionen von Systemen

Zustandsdiagramm BSP.: Event Interne Aktion Transition

Sequenzdiagramm Modellieren zeitabhängige Interaktionen zwischen Objekten Im Vergleich zu Aktivitätsdiagrammien liegt hier der Fokus auf den Nachrichtenaustausch, nicht die verschiedenen Ablaufpfade Analysephase: Darstellungen der Geschäftsprozesse auf Nachrichtenebene Entwurfsphase: Interaktionen von Systemen oder Aktoren Bsp: Kommunikation Benutzer mit GUI

Lebenslinie Eine Lebenslinie stellt einen Teilnehmer einer Interaktion dar Durch ein Stop-Symbol wird dargestellt, dass eine Lebenslinie terminiert Eine gestrichelte Linie stellt einen passiven bereich einer Lebenslinie dar Lebenslinie Stop-Symbol passive Lebenslinie

Create-Nachricht Ein Objekt wird erstellt Nachricht

Nachricht mit Rückantwort

Klassendiagramm Zentrales Konzept der UML Modellierung von Klassen und deren Zusammenhänge Analysephase: Relativ einfache Diagramme für Kommunikation mit Vorgesetzten / Partnern Entwurfsphase: Detailliert, legt spätere Programmstruktur fest Definieren nicht, in welcher Reihenfolge Klassen miteinander kommunizieren.

Klassen I Klassenname Attribute Access Modifiers Methoden Private – Protected # Package ~ Public + Datentyp

Klassen II vs. einfach, übersichtlich Für fachunkundige lesbar class BADozent { private String name; private String geburtsDatum; public void setName( String name ) … } public void benote( BAStudent student ) vs. einfach, übersichtlich Für fachunkundige lesbar Ohne programmiersprachen-spezifische Elemente

Klassen III Typ mit Angabe der Multiplizität Default-Wert (statisches) Klassenattribut

(Binäre) Assoziation Spezifiziert eine semantische Beziehung zwischen zwei Klassen BAStudent und BADozent „kennen“ sich gegenseitig, können interagieren

Assoziation - Name Durch einen Assoziationsnamen kann man die Beziehung genauer spezifizieren (e.g. „benotet“) Assoziationsname Anmerkung: Dies würde heißen, dass auch der BAStudent den BADozent benoten kann

Assoziation - Navigierbarkeit Gerichtete Assoziationen sind binäre Assoziationen, die die Navigierbarkeit einschränken Ein navigierbares Ende definiert, dass die Klasse am anderen Assoziationsende Kenntnis über die Klasse besitzt Ein nicht navigierbares Ende verbietet solch eine Kenntnis BADozent enthält eine Abhängigkeit zu BAStudent. Umgekehrt besteht keine Abhängigkeit nicht navigierbar navigierbar

Assoziation - Multiplizität Durch Hinzufügen von Multiplizitäten kann definiert werden, wieviele Referenzen des anderen Typs existieren können. Multiplizitäts-Formen: Beliebig viele „*“ Feste Zahl z.B. „1“ Zahlenbereich z.B. „1..15“ oder „1..*“ Im Beispiel: Ein BADozent kann einen bis 40 Studenten benoten Ein BAStudent kann von einem bis 15 Dozenten benotet werden

Assoziation - Rollen Definieren die Rollen der Klassen bei der Assoziation Eine Klasse kann an mehreren Assoziationen teilhaben dabei in verschiedene Rollen schlüpfen Die Rolle wird oft nach dem Attributnamen der Referenz benannt Sichtbarkeit der Rolle Rolle

Assoziation: Aggregation Spezielle Form der binären Assoziation Beschreibt, dass eine Klasse ein Teil einer anderen ist Ein Studiengang kann auch ohne BA-Studenten existieren (auch wenn das nichts Gutes für den Studiengang verheißt)

Assoziation: Komposition Starke Form der Aggregation Sagt aus, dass die Verbindung zwischen den Klassen untrennbar ist. Wird das komponierende Objekt zerstört können die komponierte Objekte nicht weiterexistieren. Im Beispiel: Ein Kurs kann ohne BA-Studenten nicht existieren

Assoziation: Generalisierung Mithilfe der Generalisierung ist es möglich, Vererbung zu modellieren Der Pfeil zeigt stets auf die Superklasse

Abstrakte Methoden Durch kursives Schreiben eines Methoden- oder Klassennamens wird dargestellt, dass es sich um eine abstrakte Eigenschaft handelt Optional wird unterhalb des Klassennamens auch {abstract} notiert abstrakt

Stereotyp <<stereotyp>> Können in allen Diagrammarten verwendet werden Spezifizieren Art des Elementes Verändern nicht die Semantik Verändern die Auskunft über Zweck und Rolle des Elementes <<stereotyp>>

Gängige Stereotypen <<utility>> Dient als Werkzeugkasten für weitere Klassen (e.g. java.util.*) <<interface>> Schnittstellendefinition <<enumeration>> Definiert einen Datentypen, der Elemente beinhalten kann (e.g. java.util.Vector) <<use>> Gibt an, dass das Element vom anderen verwendet wird

<<interface> Schnittstellen I Mit Schnittstellen kann man die in Java existierenden Interfaces modellieren Sie besitzen wie zu erwarten einen Namen und Schnittstellen-Operationen Oft werden Schnittstellen auch mit dem Stereotyp <<interface>> oberhalb des Namens gekennzeichnet PartyPerson <<interface> +feiern(): void Name Operationen

Schnittstellen II Durch einen gestrichelten geschlossenen Pfeil kann modelliert werden, dass eine Klasse ein Interface realisiert (implementiert). Gelegentlich wird dies auch durch die Notation von <<realize>> am Pfeil betont

Schnittstellen III Werden Interfaces von anderen Klassen verwendet, modelliert man dies mit einer <<use>>-Abhängigkeit

Objektdiagramm Basiert auf ein Klassendiagramm Dient zur Veranschaulichung von Klassendiagrammen Stellt die instanziierten Objekte zu einem speziellen Zeitpunkt dar Enthält nur Attribute, keine Methoden Darf nur Objekte beinhalten, deren Klassen im zugrundeliegenden Klassendiagramm definiert wurden Darf nur Attribute beinhalten, die diese Klassen definiert haben Kann unvollständig sein und nur Attribute umfassen, die für den Zustand von Bedeutung sind

Objektdiagramm Klassendiagramm Objektdiagramm Objektname Zugehörige Attributname Attributwert

Link Pendant zur Assoziation im Klassendiagramm Verbinden genau zwei Objekte Bei 1:n-Multiplizitäten werden Links zu den einzelnen Instanzen modelliert Link

Namenlose Objekte Objektnamen können weggelassen werden, wenn sie im Kontext nicht wichtig erscheinen Namenlose Instanz

Rollen Entsprechen den Rollen des Klassendiagramms Werkzeug der Wahl um Objektreferenzen zu modellieren

Paketdiagramm Frühe Phasen der Softwareentwicklung (Analyse/Design) Horizontale Strukturierung Gruppiert Klassen in Pakete Klassifizierung von Klassen Vertikale Strukturierung Gruppiert Pakete in Unterpakete Bessere Übersicht („Zoomen“)

Horizontale Strukturierung Pakete

Vertikale Strukturierung Unterpakete

Notizen Notizen sind ein zentrales Element der UML Sie können in jeder Art von Diagramm verwendet werden Sie sollen deskriptiv die modellierten Gegebenheiten verdeutlichen Notiz

Tools ArgoUML, Open Source MagicDraw UML, Kommerziell PlantUML, Open Source Innovator, Kommerziell ... und viele mehr Achten Sie bei der Wahl der Tools, ob diese UML 2.0 korrekt darstellen! Bei PlantUML ist eine Anpassung der Konfiguration nötig.