1
Q
Objektorientierung
A
Sieht Dinge der realen Welt, stellt aber nur die relevanten Aspekte dar, speichert Daten bei sich und kapselt sie ein (zum Schutz vor anderen Objekten)
2
Q
Objekte
A
Instanzen von Klassen, existieren zur Laufzeit (runtime), Mehrere Objekte können aus einer Klasse erzeugt werden
3
Q
Encapsulation
A
Daten werden in einem Objekt gespeichert, sind nur über angebotene Methoden zugänglich
4
Q
Messages
A
Eine Nachricht wird an ein Objekt gesendet, um eine Methode aufzurufen
5
Q
Polymorphism
A
Wenn eine Nachricht an Objekte unterschiedl. Klassen gesendet wird, geben diese Objekte unterschiedl. Ergebnisse zurück (Methode wird für jedes Objekt anders implementiert), zB. Druckbefehl für 2 verschiedene Dokumente gibt 2 verschiedene Dokumente aus
6
Q
Enwicklungsprozess der Objektorientierung
A
OO-Analyse –> OO-Design –> OO-Programmierung –> OO Software
- OO-Analyse: Beschreibung, wie sich eine Software verhalten soll (Beschreibt ein System als eine Gruppe interagierender Objekte, die ein konzeptionelles Modell innerhalb einer Problemdomäne generieren)
- OO-Design: basiert auf Modell der OOA, Implementierungsplan, Weiterentwicklung der Objekttypen, berücksichtigt die gewählten architektonischen, technologischen und ökologischen Einschränkungen, typische Ausgabe ist ein Klassendiagramm
- OO-Programmierung: Konzept der Objekte steht im Mittelpunkt, basiert auf Ergebnissen der OOD, OO-Sprache zB. Java
7
Q
Unified Modelling Language (UML)
A
- Modellierungssprache
- Standard der Object Management Group (OMG)
- Standardisierung von verschiedenen objektorientierten Notationen und Methoden in allen Phasen der Softwareentwicklung durch die Verwendung verschiedener Arten von Modellen (daten-, objekt- und prozessorientiert)
8
Q
UML - Konzept
A
- Unterstützung von Analyse und Design objektorientierter Softwaresysteme
- Enthält mehrere Ansichten auf ein System
- Jede Ansicht spezifiziert und dokumentiert ein System aus einer anderen Perspektive
- Jede Ansicht wird von einem oder mehreren Diagrammen unterstützt
- UML ist kein Prozessmodell
9
Q
UML - Struktur
A
- Grundelemente: Objektorientierte Notationselemente, zusätzliche Elemente zur Beschreibung des modellierten Systems (zB. Aktivitäten, Akteur,…)
- Diagramme: Zusammensetzung von Grundelementen, stellen eine bestimmte Ansicht auf ein System dar
- Komplettes Modell: alle Diagramme und Grundelemente, durch verschiedene Diagrammtypen werden verschiedene Sichten auf das Gesamtmodell dargestellt
10
Q
UML - Ansichten
A
- Use-Case-View
- Logical View
- Implementation View
- Process View
- Deployment View
11
Q
UML - Use-Case-View
A
- Beschreibt high-level Funktionalitäten eines Systems
- Wird von Stakeholdern, Designern, Entwicklern und Testern verwendet
- Dargestellt durch Anwendungsfalldiagramme
- Dient als Grundlage für andere Ansichten
12
Q
UML - Logical View
A
- Beschreibt die zu entwickelnden und zu implementierenden Funktionalitäten sowie die statischen und dynamischen Aspekte eines Systems
- Meist von Designern und Entwicklern verwendet
- Dargestellt durch Klassendiagramme, Objektdiagramme (statische Ansicht), Zustandsdiagramme, Interaktions- und Aktivitätsdiagramme (dynamische Ansicht)
13
Q
UML - Implementation View
A
- Beschreibt die Organisation von Softwarekomponenten
- Teilt die logischen Entitäten in tatsächliche Softwarekomponenten auf
- Dargestellt durch Komponentendiagramme
- Meist von Entwicklern verwendet
14
Q
UML - Process View
A
- Beschreibt Prozesse in einem System
- Meist von Entwicklern und Testern verwendet
- Dargestellt durch Zustands- Interaktions- und Aktivitätsdiagramme
- Unterstützt Gleichzeitigkeit und Behandlung von asynchronen Ereignissen
15
Q
UML - Deployment View
A
- Beschreibt die physische Architektur und die Zuordnung von Komponenten zu Architekturelementen
- Meist von Designern, Entwicklern und Managern verwendet
- Dargestellt durch Paket- Komponenten und Verteilungsdiagramme
16
Q
UML Diagramme
A
- Use-Case-Diagrams
- Structural Diagrams
17
Q
UML - Use-Case-Diagrams
A
- Use Cases beschreiben die Funktionalität, die ein System bereitstellen muss
- Summe aller Use Cases umfasst die technischen Anforderungen eines Systems
- Use Cases definieren die Schnittstellen zwischen einem Benutzer und einem System
- Spezifikation wird zusammen mit dem Kunden entwickelt
18
Q
UML - Structural Diagrams
A
Klassendiagramme
- Darstellung der statischen Struktur eines Softwaresystems
- Beschreibung der logischen Beziehungen zwischen Strukturelementen
- Keine Aktivität oder Steuerungslogik
Objektdiagramme
- Instanzen eines Klassendiagramms
- „Snapshot“ eines Systems zur Laufzeit
19
Q
Abstract Classes
A
- Definition/Aggregation von gemeinsamen Eigenschaften
- Erlaubt keine Erzeugung von Objekten
- Vorlage zum Erstellen von Unterklassen
- Abstrakte Methoden werden automatisch überschrieben
- Name von abstraktiven Klassen wird kursiv geschrieben
20
Q
Associations
A
- Beschreibt die Beziehung zwischen 2 Klassen
- Wird durch Linie dargestellt, die die 2 Klassen verbindet
- Die an die Assoziation angehängte Multiplizität min..max definiert die minimale oder maximale Anzahl der Assoziationen zwischen den Objekten der beiden Klassen
- Aggregation: Bezeichnet eine „hat eine“ Beziehung
- Zusammensetzung/Composition: Bezeichnet eine „besitzt eine“ Beziehung, stärkere Variante der Aggregation
21
Q
Inheritance
A
- Bezeichnet Beziehung zwischen Eltern-/Oberklasse und Unterklasse
- Die Oberklasse vermacht Attribute an die Unterklasse
- Unterklasse hat alle Attribute der Oberklasse (und noch mehr)
- Darstellung mit einer Linie und einem Pfeil, der auf die Elternklasse zeigt
- Zweck: Wiederverwendung von Code durch Objekte, die auf zuvor erstellten Objekten basieren können
22
Q
Instantiation
A
- Anlegen von Objekten nach der Vorlage einer Klasse zur Laufzeit
- Objekt = Instanz einer Klasse
- Klasse = Attribute und Methoden
- Objekt = Attributwerte und Nachrichten
23
Q
Aktivitätendiagramm
A
- Verwendung zur Modellierung von Arbeitsabläufen in einem System
- Zentrales Element ist die Aktivität (Aktivität = Aktion)
- Aktivitäten sind nach Verantwortlichkeiten strukturiert
- Verschiedene Ansichten:
Konzeptionsansicht: zB. Arbeitsprozesse
Implementierungsansicht: zB. Methoden von Objekten
24
Q
Model-driven Development (MDD)
A
- Konzept für die Entwicklung von Software
- Das Softwaresystem wird durch ein abstraktes Modell beschrieben (zB. Basierend auf UML)
- Das abstrakte Modell ist typischerweise unabhängig von der Zielprogrammiersprache, der Betriebssystem-plattform oder einer anderen zugrunde liegenden Technologie
- Das abstrakte Modell ermöglicht eine automatische Umwandlung in Code für mehrere Ziel-Betriebssystem-plattformen
- Der resultierende Code kann von Skelettklassen bis zu vollständigen Softwareprodukten variieren
25
Round-Trip-Engineering - MDD
Änderungen am Modell können automatisch in Code umgewandelt werden (und umgekehrt)
- Modell zu Code: Forward Engineering,
- Code zu Modell: Reverse Engineering
26
Vorteile der MDD
- Reduzierte Entwicklungszeit
- Zeitloses Modell, altert mit Domain und nicht mit Technologie
- Verbesserte Dokumentation des Softwaresystems: Modell bessere Dokumentation als Code, Verbesserte Lesbarkeit, immer konsistent mit Code durch automatische Generierung
- Einfachere Anpassung des Systems
- Plattform- und Programmiersprachen-Unabhängigkeit
27
Model-driven Architecture (MDA)
- Eingeführt durch OMG
- Trennt Geschäfts- und Anwendungslogik von der zugrunde liegenden Implementierungsplattform
- Forward Engineering Ansatz: es werden erste abstrakte Modelldiagramme entwickelt, die später in Code transformiert werden
- Ziel: Trennung von konzeptionellem Entwurf und Implementierungsarchitektur
28
Vorteile MDA für den Software Lebenszyklus
- Implementierung: Ermöglicht die Integration neuer Zielsoftwareplattformen basierend auf bestehenden Designmodellen
- Integration: Integration einfacher, da Implementierungs- und Entwurfsmodell schon existieren
- Wartung: Die Verfügbarkeit des Designs in einer maschinenlesbaren Form gibt Entwicklern direkten Zugriff auf die Spezifikation des Systems, wodurch die Wartung wesentlich vereinfacht wird
- Testen und Simulieren: Die Entwurfsmodelle können anhand vorhandener Anforderungen validiert werden, und ausführbare Modelle können verwendet werden, um das Systemverhalten zu simulieren
PWIN
flashcards
Decks in class (8)
# Cards
