8. ICS Development II Flashcards
1
Q
Die Idee von Objektorientierung
A
2
Q
Objektorientierte Softwareentwicklung
A
- Betrachtung von Software als eine Sammlung interagierender Objekte, die zusammenarbeiten, um Aufgaben zu erledigen
- Objekte: Dinge, die in einem Computersystem auf Nachrichten reagieren können
- Konzeptionell werden keine Prozesse, Programme, Dateien definiert - nur Objekte
3
Q
Grundlegende OO-Elemente
A
- Class / Klasse: Vorlage für ein Objekt; es enthält Variablen, Konstanten und Methoden
- Object: Instanzen von Klassen, die während der Laufzeit existieren; mehrere Objekte können aus einer Klasse initiiert werden
- Association: Beziehung zwischen Klassen oder Objekten
- Instantitation / Instanziierung: Erstellen von Objekten nach der Vorlage einer Klasse während der Laufzeit
4
Q
Grundlegende OO - Konzepte
A
- Encapsulation / Verkapselung: Daten werden in einem Objekt gespeichert und können nur über die angebotenen Methoden erreicht werden
- Inheritance / Vererbung: Klassen können Attribute oder Methoden von anderen Klassen übernehmen. Die vererbende Klasse wird „Super-Klasse“ oder „Eltern- Klasse“ und die erbende Klasse wird „Unter-Klasse“ genannt
- Messages / Mitteilungen: Eine Nachricht wird an das Objekt gesendet um es anzuweisen, eine Methode auszurufen
- Polymorhism / Polymorphismus: Wenn eine Nachricht an Objekte unterschiedlicher Klassen gesendet wird, geben diese Objekte unterschiedliche Ergebnisse zurück, da die aufgerufene Methode für jedes Objekt anders implementiert werden kann (Bsp. wird die Nachricht „print“ and die Objekte „Adressliste“ und „Bestellung“ gesendet)
5
Q
Objektorientierte Analyse (OOA)
A
- Beschreibt ein System als eine Gruppe von interagierenden Objekten und generiert ein konzeptionelles Modell innerhalb eines Problem Domains
- Daraus ergibt sich eine Beschreibung, wie sich eine Software verhalten soll
- Das konzeptionelle Modell beschreibt keine Implementierungsdetails; diese werden in der Designphase entwickelt
6
Q
Objektorientiertes Design (OOD)
A
- Nimmt das durch die objektorientierte Analyse erzeugte konzeptionelle Modell als Input
- Verfeinert jeden Objekttyp, um entsprechend seinem Umgebungskontext in einer bestimmten Sprache implementiert zu werden (=Implementierungsdetails)
- Berücksichtigt die gewählte Architektur sowie technologische Einschränkungen
- Typische Ausgabe: Klassendiagramm
7
Q
Objektorientierte Programmierung (OOP)
A
- OOP ist ein Programmierparadigma (Muster) für Software
- Es dreht sich um das Konzept der „Objekte“, die aus Datenstrukturen und Methoden bestehen
- Es nimmt die Ergebnisse der OOD als Eingabe
- OO-Sprachen: Java, C++, C#.NET, VB.NET
8
Q
Unified Modeling Language (UML)
A
- Modellierungssprache, die 1996 von Bosch, Jacobson und Raumbaugh entwickelt wurde
- Standard der OMG (Object Mangement Group)
- Standardisierung von:
- Verschiedenen objektorientierten Notationen
- Methoden in allen Phasen der Softwareentwicklung
- Standardisierung erfolgt durch die Verwendung verschiedener Arten von Modell (datenorientiert, objektorientiert, prozessorientiert, usw.)
9
Q
UML Konzept
A
- Unterstützt Analyse und Design von objektorientierten Softwaresystemen
- UML beinhaltet verschiedene Sichten auf ein System
- Jede Sicht spezifiziert und dokumentiert ein System aus einer anderen Perspektive
- Jede Sicht wird von einem oder mehreren Diagrammen unterstützt
• UML ist kein Prozessmodell -> UML definiert keinen Prozess, um UML Modelle zu erschaffen
10
Q
UML Struktur
A
• Grundelemente:
- Objektorientierte Notationselemente
- Zusätzliche Elemente zu Beschreibung des modellierten Systems (z.B Aktivitäten,…)
• Diagramme:
- Zusammensetzung von Notationselementen
- Stellt eine bestimmte Sicht auf ein System dar
• Komplettes Modell:
- Basiert auf den Grundelementen
- Verschiedene Ansichten des gesamten Modells durch verschiedene Diagrammtypen
11
Q
UML Views
A
12
Q
Use Case View / Fallansicht
A
- Beschreibt high level Funktionalitäten des Systems
- Wird von Stakeholdern, Designern, Entwicklern und Testern benutzt
- Dargestellt durch Use Case Diagramme
- Dient als Grundlage für andere Ansichten
13
Q
Logical View / Logikansicht
A
- Beschreibt die zu entwickelnden und zu implementierenden Funktionalitäten
- Beschreibt statische und dynamische Aspekte eines Systems
- Meist von Designern und Entwicklern verwendet
- Dargestellt durch Klassendiagramme, Objektdiagramme (statische Ansicht), Interaktions- und Aktivitätsdiagramme (dynamische Ansicht)
14
Q
Implementation View / Implementierungsansicht
A
- Beschreibt die Organisation von Softwareelementen bzw. Softwarekomponenten
- Teilt die logischen Einheiten in tatsächliche Softwarekomponenten
- Meist von Entwicklern verwendet
- Dargestellt durch Komponentendiagramme
15
Q
Process View / Prozessansicht
A
- Beschreibt Prozesse in einem System
- Meist von Entwicklern und Testern verwendet
- Dargestellt durch Zustands-, Interaktions- und Aktivitätsdiagramme
- Unterstützt Behandlung von asynchronen Ereignissen
17
Q
Use Case Diagramm
A
- Use Cases / Anwendungsfälle beschreiben die Funktionalität, die ein System bereitstellen muss
- Summe aller „Use Cases“ umfasst die technischen Anforderungen eines Systems
- Use Cases definieren die Schnittstelle zwischen Benutzer und dem System
- Die Spezifikation wird zusammen mit dem Kunden entwickelt
siehe Folie 28ff
