Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

PWIN > UML-Programmierung > Flashcards

UML-Programmierung Flashcards

VL 7

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Objekte

A

Instanzen von Klassen, existieren zur Laufzeit (runtime), Mehrere Objekte können aus einer Klasse erzeugt werden

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Encapsulation

A

Daten werden in einem Objekt gespeichert, sind nur über angebotene Methoden zugänglich

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Messages

A

Eine Nachricht wird an ein Objekt gesendet, um eine Methode aufzurufen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

UML - Ansichten

A
  • Use-Case-View
  • Logical View
  • Implementation View
  • Process View
  • Deployment View
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
Q

Round-Trip-Engineering - MDD

A

Änderungen am Modell können automatisch in Code umgewandelt werden (und umgekehrt)

  • Modell zu Code: Forward Engineering,
  • Code zu Modell: Reverse Engineering
26
Q

Vorteile der MDD

A
  • 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
Q

Model-driven Architecture (MDA)

A
  • 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
Q

Vorteile MDA für den Software Lebenszyklus

A
  • 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 (8 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions