7. 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 cKonzeptionelle 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
16
Q
Deployment View / Bereitstellungsansicht
A
- Beschreibt die physische Architektur und die Zuordnung von Komponenten zu Architekturelementen
- Meist von Designern, Entwicklern und Managern verwendet
- Dargestellt durch Paket-, Komponenten- und Deployment-Diagramme
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
18
Q
Strukturelle Diaramme
A
• Class Diagrams / Klassendiagramme:
- Darstellung der statischen Struktur eines Softwaresystems
- Beschreibung der logischen Beziehung zwischen Strukturelementen
- Keine Aktivität oder Steuerungslogik
• Object Diagrams / Objektdiagramme:
- Instanzen eines Klassendiagramms
- „Snapshot“ eines Systems während der Laufzeit
19
Q
UML Klasse
A
- Klassen werden durch Rechtecke dargestellt, die den Namen der Klasse, ihre Attribute und Methoden enthalten
- Klassenname ist in Singular und beginnt mit einem Großbuchstaben
- Attribute und Methoden sind durch horizontale Linien getrennt
- „+/-„ Attribut/Methode ist öffentlich/privat
- Klassenattribute:
- Gehören zu einer Klasse, nicht zu einem Objekt
- Haben für alle Instanzen (Objekte) den gleichen Wert
- z.B. Attribut „Number“, um die Anzahl der erstellten Objekte für eine Klasse zu zählen
- Klassenattribute sind im Klassendiagramm unterstrichen
• Klassenmethode / Funktionen:
- Klassenmethoden werden innerhalb einer Klasse ausgeführt, nicht mit dem Objekt
- z.B. Anzahl der erstellten Objekte einer Klasse zählen
- Klassenmethode ist im Klassendiagramm unterstrichen
20
Q
Abstrakte Klassen
A
- Definition / Aggregation von gemeinsamen Eigenschaften
- Eine abstrakte Klasse erlaubt keine Instanziierung (Erzeugen) von Objekten
- Vorlage zum Erstellen von Unterklassen
- Abstrakte Methoden werden standardmäßig „überschrieben“
- Der Name von abstrakten Klassen ist kursiv geschrieben
21
Q
Associations / Assoziationen
A
- Beschreiben die Beziehung zwischen zwei Klassen
- Wird durch eine Linie dargestellt, die die beiden Klassen verbindet
- Die an dem Verband angehängte Mulitplizität min… max definiert die minimale oder maximale Anzahl der Assoziationen zwischen den Objekten beider Klassen
- (*) bezeichnet eine beliebige Anzahl von Objekten
- Aggregation: Bezeichnet eine „hat eine“ Beziehung
- Komposition: Stärkere Variante einer Aggregation • Bezeichnet eine „besitzt eine“ Beziehung
siehe Folie 37
22
Q
Inheritance
A
- Bezeichnet eine Beziehung zwischen Elternklassen und Unterklassen
- Wird Am Ende durch eine Linie mit einem leeren Pfeil dargestellt, der auf die Elternklasse zeigt
- Class 2 erbt von Class 1
- Zweck: Wiederverwendungscode (Reuse code), durch Objekte, die auf zuvor erstellten Objekten basieren können
23
Q
Instantiation / Instanziierung
A
- Darstellung der Relation „Klasse-Objekt“
- Ein Objekt ist eine Instanz für eine Klasse
- Klasse - Attribute - Methoden
wird zu
• Objekt - Attributwert - Nachrichten / Messages
24
Q
Activity Diagram / Aktivitätsdiagramm
A
- Aktivitätsdiagramme werden zum Modellieren von Workflows in einem System verwendet
- Zentrales Element „Aktivität“: Eine Aktivität ist jede Art von Aktion
- Aktivitäten sind nach Verantwortlichkeiten strukturiert
- Verschiedene Ansichten: Konzeptionsansicht (z.B. Arbeitsprozesse), Implementationsansicht (z.B. Methoden von Objekten)
25
Q
Model-driven Development (MDD) / Modellgetriebene Entwicklung
A
- Konzept für die Entwicklung von Software
- Das Softwaresystem wird durch eine abstraktes Modell (z.b basierend auf UML) beschrieben
- Das Abstrakte Modell ist typischerweise unabhängig von der Zielprogrammiersprache, der Betriebsplattform oder einer anderen zugrundeliegenden Technologie
- Abstrakte Modell ermöglicht eine automatische Umwandlung in Code für multiple target OS Plattformen
- Der resultierende Code kann von Skelettklassen bis zu vollständigen Softwareprodukten variieren
26
Q
Abstraktes Modell
A
- Abstraktion des realen Softwaresytstems (nicht der realen Welt)
- Nur die relevanten Aspekte eines Systems sind enthalten - irrelevante werden ignoriert
- Verschiedene Abstraktionslevel sind möglich
27
Q
Round-Trip Engineering
A
• Änderungen im Modell können automatisch zu Code umgewandelt werden und umgekehrt
28
Q
Automatisierung im Entwicklungsprozess
A
- MDD fördert die Automatisierung im Entwicklungsprozess
- Automatisierte Analyse und Überprüfung des Modells: Da Modelle keine Implementierungsdetails enthalten sind sie einfacher zu analysieren
- Automatische Code-Generierung aus dem Modell, die garantiert, dass der Code mit dem Modell übereinstimmt
- Laufzeitüberwachung anhand des Modells: Stellt sicher, dass die Implementierung dem im Modell angegeben Verhalten folgt
- Automatisierte Testgenerierung: Modelle können verwendet werden, um Testfälle für die Implementierung zu generieren
29
Q
Vorteile von MDD
A
- Reduzierte Entwicklungszeit
- Das Modell ist zeitlos: Es wird mit der Domain altern, nicht mit der Technologie
- Verbesserte Dokumentation des Softwaresystems
- Modell ist eine bessere Dokumentation als Code
- Verbesserte Lesbarkeit
- Wegen automatischer Generierung immer konsistent mit dem Code
- System kann einfacher angepasst werden
- Unabhängig von Plattform und Programmiersprache
30
Q
Model-Driven Architecture (MDA) / Modellgetriebene Architektur
A
- MDA wurde von der Object Management Group (OMG) eingeführt
- Trennt die Geschäfts- und Anwendungslogik von der zugrundeliegenden Implementierungsplattform
- Ist ein Forward Engineering Ansatz, bei dem erste abstrakte Modelldiagramme entwickelt werden, die später in Code transformiert werden
- Ziel der MDA ist es, den konzeptionellen Entwurf von der Implementierungsarchitektur zu trennen
31
Q
MDA: Entwicklungsprozess
A
- Entwickler entwickeln plattformunabhängige Modelle (PIM) für die Software (z. B. UML)
- Diese dokumentieren die betriebswirtschaftliche Funktionalität einer Software (unabhängig vom spezifischen Code)
- Nachdem die Plattform für die Zielimplementierung gewählt wurde, können plattformunabhängige Modelle automatisch in plattformspezifische Modelle (PSM) übersetzt werden
- Diese werden verwendet, um die Implementierung für die gewählte Plattform zu steuern
32
Q
Vorteile von MDA für den Software-Lebenszyklus
A
- Implementierung: MDA ermöglicht Integration neuer Softwareplattformen basierend auf dem bestehenden Designmodell
- Integration ist einfacher, da sowohl Implementierung als auch Entwurfmodell zum Zeitpunkt der Integration existiert
- Wartung: Die Verfügbarkeit des Designs in einer maschinell lesbaren Form ermöglicht direkten Zugriff auf die Spezifikation des Systems, wodurch die Wartung verbessert wird
- Testen und Simulieren: Entwurfsmodelle können anhand vorhandener Anforderungen validiert werden, und ausführbare Modelle können verwendet werden, um das Systemverhalten zu simulieren
