Brainscape's Knowledge GenomeTM

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


See full index

Modellierung > Objektorientierte Analyse und Design (OOAD) mit der Unified Modeling Language (UML) > Flashcards

Objektorientierte Analyse und Design (OOAD) mit der Unified Modeling Language (UML) Flashcards

1
Q

Definition Objektorientierung

A

Gegenstände der Realität werden als Objekte abgebildet

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

Polymorphismus

A

Verschiedene Arten von Objekten können auf die gleiche Nachricht reagieren, welche Methode tatsächlich ausgeführt wird, entscheidet sich erst zur Laufzeit (Late Binding)

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

Objekte haben…

A
  • Zustand (Werte der Attribute)
  • Verhalten (Methoden beschreiben, wie auf Nachrichten reagiert wird)
  • Identität (zwei Objekte mit identischen Werten sind zwei einzigartige Objekte)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Kapselung

A

Informationen werden vor einem Teil der Applikation verborgen gehalten

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

Zweck OOAD

A
  • Software soll funktionale Anforderungen erfüllen
  • dazu kommen nicht-funktionale Anforderungen (Plattformen, Wartbarkeit, Erweiterbarkeit, Skalierbarkeit, Wiederverwendbarkeit…)
  • techn. Anforderungen: z.B. Spaghetticode und Seiteneffekte vermeiden
  • Anforderungen analysieren und Aufbau entwerfen, BEVOR Code geschrieben wird
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

3 mögliche(!) Schritte zu guter Software

A

1) Software macht, was Kunde möchte
2) Anwenden von OO-Prinzipien für Flexibilität (ein Konzept pro Klasse, keine leeren Attribute)
3) Anstreben eines wartbaren und wiederverwendbaren Designs (bei Änderungen möglichst wenige Klassen ändern müssen, delegieren von Aufgaben)

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

Separation of Concerns

A

Gesamtcode wird aufgeteilt, sodass jeder Teil für eine bestimmte Aufgabe zuständig ist

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

CRC-Cards

A

Class-Responsibility-Collaboration Cards trennen Zuständigkeiten von Klassen

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

Vorteile OOAD

A
  • Kunde wird zufriedengestellt (Programm funktioniert und kann verändert werden)
  • Programm kann für nächsten Kunden wiederverwendet werden
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Unified Modeling Language (UML)

A

Graphisches Modell um Anforderungen an Softwaresystem und technischen Aufbau des Systems besser zu verstehen

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

Vorteile UML

A

Eindeutigkeit: Festlegen beim Zeichnen
Verständlichkeit: gibt komplexe Zusammenhänge wieder
Ausdrucksstärke: Fokus Gesamtsystem oder Teilaspekt
Standardisierung: vereinfach Kommunikation in Projekten
Plattformunabhängigkeit: keine Festlegung

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

Kriterien, welches der 14 UML-Diagrammtypen genutzt werden soll

A

Zweck: Wozu dient das Modell?
Zielgruppe: Für wen ist es gedacht?
Kosten/Nutzen-Verhältnis des Modells

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

UML-Diagrammarten

A
  • Verhaltensdiagramme (weiter: Interaktionsdiagramme)

- Strukturdiagramme

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

Weitere Methoden, die bei Analyse und Design zum Einsatz kommen

A
  • Screen-Prototypes (GUI für Anforderungsanalyse)

- Use-Case-Dokumente (verbal formuliert oder UML für Anwender oder Entwickler)

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

Objektorienterte Analyse

A

Verstehen der Kundenanforderungen durch Sprechen, Fragen stellen, Diskutieren, versch. Blickwinkel

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

Definition Use Case (Aufteilen der Gesamtaufgabe)

A
  • Anwendungsfall
  • Ein Akteur interagiert mit dem zu entwerfenden
    System mit einer bestimmten Absicht
  • dafür: Semi-Strukturierte Methode der Dokumentation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Eigenschaften Use Case (4)

A

1) Bringt dem Anwender einen Nutzen
2) Hat definierten Anfang und definiertes Ende
3) Wird von einem Akteur außerhalb des Systems initiiert
4) Muss alle Pfade vom Ausgangspunkt bis zum Ziel enthalten

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

Inhalt Use Case Dokument

A
  • Name (ID)
  • Status
  • Version
  • Description
  • Actors
  • Basic Flow und Alternative Flow
  • Trigger
  • Pre- und Postconditions
  • Related Use Cases
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Prinzipien Use Case (Diagramme)

A

1) encapsulate what varies
2) understand requirements (Entwickler muss System verstehen)
3) code to interfaces rather that to an implementation (Code einer Klasse soll möglichst unabhängig vom Code anderer Klassen sein)

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

Domänenanalyse

A
  • Beschreiben der Aufgabe in Sprache des Anwenders

- Sammeln von Informationen (Kunde, Anwender, existierende Systeme, Theorien und Techniken der Domäne)

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

Use-Case-Diagramme

A
  • beschreiben auf hoher Ebene Funktionalität eines Systems (Was?, aber nicht Wie?)
  • Abstrahieren von Details
  • geben keine Reihenfolge der Use Cases vor
  • Zweckmäßigkeit statt Vollständigkeit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Bestandteile Use Case Diagramm

A
  • großes Rechteck definiert Systemgrenze
  • Akteur (EXTERNER Benutzer oder EXTERNES System interagiert mit System)
  • Anwendungsfall (Funktionalität des Systems, welches aus einer Menge von Aktionen besteht)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Assoziation

A
  • Bezeichnung zwischen Akteur und Anwendungsfall
  • gerichtet: mit Pfeilspitze und Multiplizität
  • ungerichtet: lässt offen, ob Akteur den Use Case initiieren kann
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Multiplizität

A

Gibt an, wie viele Objekte bei einem Aufruf des Use Cases von wie vielen Akteuren bearbeitet werden können (ist immer zu einem bestimmten Zeitpunkt zu verstehen)

25
Q

Beziehungen zwischen Anwendungsfällen

A

<>: gemeinsame Funktionalität wird in mehreren Use Cases verwendet
<>: ein Use Case erweitert einen anderen

26
Q

Generalisierung (Vererbung)

A
  • zwischen Akteuren mit Pfeilen (unausgefüllte Spitze)

- zwischen Use Cases möglich, aber unüblich

27
Q

Klassendiagramme

A
  • beschreiben Struktur des OO-Systems
  • für Diskussion mit Anwender (auf wesentliche Klassen beschränken)
  • Vorlage für Entwicklung (müssen detailliert sein)
  • im Use-Case-Dokument: Substantive meist Klassen, Verben meist Methoden
28
Q

Elemente Klassendiagramm

A
  • Klassen (Attribute und Methoden)

- Generalisierungspfeile (von spezielle zu allgemeine Klasse)

29
Q

Assoziation und Kardinalität

A

Assoziation: Beziehung zwischen zwei Klassen
Kardinalität: wie viele Objekte können an Assoziation beteiligt sein
- kann mit Namen und Dreieck für Leserichtung versehen werden

30
Q

Aggregation (Raute an Pfeil NICHT ausgefüllt)

A

Form der Assoziation, bei der sich ein Objekt der einen Klasse u.a. aus einem Objekt der anderen Klasse zusammensetzt (Bsp.: Wohnzimmer aus Couch und Tisch)

31
Q

Komposition (Raute an Pfeil aufgefüllt)

A
  • Aggregation, bei der ein Objekt untrennbar mit einem Ganzen verbunden ist (wenn es das Ganze nicht mehr gibt, gibt es auch die Teile nicht mehr) –> Baum aus Stamm und Ast
  • Multiplizität auf Seite des Ganzen immer 1 (kann daher weggelassen werden)
  • Klasse des Ganzen erzeugt ihre Teile selbst
32
Q

Grundregeln Klassendesign

A
  • was sich ändern kann wird möglichst in einer einzigen Klasse gekapselt
  • Gemeinsamkeiten werden in Klasse auf höherer Ebene “zusammengezogen”
33
Q

Detaillierungsgrad von Klassendiagrammen

A
  • hängt vom Zweck des Diagramms ab
  • erweiterbares Klassendesign wichtig
  • sollten alle relevanten Klassen, Attribute und Methoden enthalten (müssen nicht zwingend alle Notationselemente enthalten)
34
Q

Attribute in Klassendiagrammen

A
  • alles außer Attributname ist optional
  • Klassenattribute werden unterstrichen
  • Datentyp nach :
  • Defaultwerte nach =
  • Attribute, die nicht gespeichert, sondern berechnet werden, werden mit / gekennzeichnet (z.B. Alter aus Geburtsdatum)
35
Q

Sichtbarkeiten von Attributen

A

+ public, für alle Klassen sichtbar
# protected, für eigene Klassen sichtbar
- private, für andere Klassen unsichtbar
~ package, innerhalb des Paketes sichtbar

36
Q

Multiplizitäten in Klassendiagrammen

A
  • wird bei einem Attribut in Form [4], [0..6], [1..*] angegeben
  • Attribute, die Assoziation implementieren werden im Klassendiagramm weggelassen (Multiplizität steht statt Assoziation)
37
Q

Eigenschaften von Attributen

A
  • am Ende der Attributzeile in geschweiften Klammern
  • {readOnly} Attributwert kann nicht verändert werden
  • {unique} Jeder Attributwert darf bei maximal einem Objekt vorkommen
38
Q

Reihenfolge / Syntax Notationselemente für Attribute

A

Sichtbarkeit / Name : Typ Multiplizität = Defaultwert {Eigenschaft}

39
Q

Eigenschaften von Methoden

A
  • in für elementare Datentypen
  • inout für komplexe Datentypen
  • {sequence} –> Tupel: Werte sind geordnet
  • {bag} –> Menge: Werte sind ungeordnet, Reihenfolge nicht definiert
40
Q

Reihenfolge / Syntax Notationselemente für Methoden

A

Sichtbarkeit Name (Parameterliste) : Rückgabetyp {Eigenschaft}

41
Q

Methoden in Klassendiagrammen

A
  • Parameter enthalten mindestens Name und Typ, durch Komma voneinander getrennt
  • Multiplizität in Parameterliste definiert, aus wie vielen Teilen ein Parameter bestehen darf
  • Überladene Methoden werden mehrfach aufgeführt
42
Q

Reflexive Assoziationen

A
  • Rollen besonders wichtig (z.B. Chef ist selbst auch ein Mitarbeiter)
  • Sichtbarkeit von Rollen kann definiert werden
43
Q

Assoziationen: XOR

A

Objekte der beteiligten Klassen dürfen nur an einer der Assoziationen beteiligt sein

44
Q

Assoziationen: Navigierbarkeit

A
  • in welcher Richtung haben Assoziationen Kenntnis voneinander (Pfeilrichtung)
  • Objekte einer Klasse können als Attribut ein Objekt einer anderen Klasse bekommen
  • Assoziation mit x verbietet Navigierbarkeit
  • Assoziationen ohne Pfeil und x spezifizieren Navigierbarkeit gar nicht
45
Q

Assoziationen: Qualifizierer

A
  • geben an, anhand welcher Attribute einem Objekt der Klasse ein Objekt der assoziierten Klasse zugeordnet wird
46
Q

Assoziationen: Assoziationklassen

A
  • Modellierung der Eigenschaften einer Assoziation
  • gehören zu keiner Klasse (nur Assoziationsklasse)
  • bei m:n-Assoziationen
  • Umwandlung in normale Klassen nötig
47
Q

Assoziationen: n-äre Assoziationen

A
  • Beziehungen zwischen zwei oder mehr Klassen
  • Symbol: Raute
  • keine Navigierbarkeit oder Qualifizierer
  • Multiplizitäten beziehen sich auf Kombinationen aller anderen Objekte (Untergrenze meist 0)
48
Q

n-äre Assoziationen nicht praxisgängig weil…

A
  • Reduzieren Komplexität nicht so wie binäre Assoziationen (Sinn von Modellen)
  • können in mehrere binäre Assoziationen aufgelöst werden
  • nicht direkt implementierbar
49
Q

Abhängigkeiten in Klassendiagrammen

A
  • Klasse kann nicht ohne andere Klasse implementiert werden
    Gründe der Abhängigkeit:
  • <>: Methodenaufruf
  • <>: Erzeugung von Instanzen
50
Q

Generalisierung in Klassendiagrammen

A
  • UML erlaubt Mehrfachvererbung (Java nicht)

- Vererbungsbeziehungen können zu Generalisierungsgruppen zusammengefasst werden (z.B. Anspruch und Eigentum)

51
Q

Generalisierung in Klassendiagrammen: Eigenschaften

A
  • Unterklassen umfassen zusammen alle Objekte der Oberklasse oder nicht ({complete}, {incomplete})
  • Unterklassen überlappen sich oder nicht ({overlapping}, {disjoint})
52
Q

Generalisierung in Klassendiagrammen: Stereotypen

A
  • modellieren nicht Realität, sondern beschreiben andere Notationselemente
  • <>: Aufzählungstypen
  • <>: Klassen stellen statische Attribute und Methoden für andere Klassen bereit (meist abstrakt)
53
Q

Templates in Klassendiagrammen

A
  • Vorlage für Klasse (abhängig von Parameter)
  • Typ des Parameters beliebig (kein Parameter = beliebige Klasse)
  • um Datenstrukturen für beliebige Klassen zu definieren (Stapel, Listen, Mengen)
  • gestrichelter Pfeil von Klasse zu Template (Binden der Übergabe)
54
Q

Schnittstellen in Klassendiagrammen

A
  • Vorschrift, welche Attribute und Methoden eine Klasse implementieren muss (implementieren selbst keine), die Schnittstelle implementiert
  • <>
55
Q

Implementierung von Schnittstellen

A
  • andere Klasse können Methoden und Attribute der implementierenden Klasse aufrufen (muss diese aber dann implementiert haben)
  • realisierte Schnittstelle: Modellierung als Ball-End
  • benötigte Schnittstelle: Modellierung als Socket-Symbol
56
Q

Aktivitätsdiagramme

A
  • beschreiben Verhalten von Systemen
  • zur Detaillierung von Use Cases
  • Modellierung von Geschäftsprozessen
  • Abläufe in Systemen beschreiben
  • können sogar Algorithmen beschreiben
57
Q

Sequenzdiagramme

A
  • gleiche Anwendungsfelder wie Aktivitätsdiagramme
  • Schwerpunkt liegt auf Chronologie der ausgetauschten Nachrichten zwischen Akteuren und System
  • sobald es parallele Prozesse gibt, muss Aktivitätsdiagramm genommen werden
  • Wie und in welcher Reihenfolge wird kommuniziert?
58
Q

Synchrone Kommunikation

A

findet in Echtzeit statt (ortsunabhängig), z.B. Chat

59
Q

Asynchrone Kommunikation

A

findet zeitliche versetzt statt, z.B. Email

Modellierung (3 decks)

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