Software Engineering WS01/02 Andreas Unterweger

In einem Remote-Interface werden jene Methoden deklariert, die verteilt aufrufbar sein sollen. Eine Serverklasse implementiert das Interface und instanziiert eine oder mehrere Instanzen, sogenannte remote objects. Die Serverklasse ist von UnicastRemoteObject abgeleitet. Remote Objects werden bei einer rmiregistry registriert, die von Clients abgefragt werden kann (lookup). Mit Hilfe der Rmiregistry erhalten die Clients Referenzen auf die remote objects und können so die Methoden aufrufen. Beim Aufruf einer remote method übergebene Parameter werden serialisiert an das remote object übertragen und die Methode wird am Server ausgeführt. Der Rückgabewert wird an den Client serialisiert zurückübertragen. Die Übertragung der Daten zwischen Client und Server übernehmen sogenannte stubs (proxy) und skeletons. Diese werden mit Hilfe von rmic erzeugt. Ein Stub ist eine lokale Repräsentation (proxy), die ein Client verwendet, um mit remote objects zu kommunizieren. Er übernimmt das Packen/Entpacken der Argumente und sendet/empfängt die serialisierten Daten. Auf der Serverseite übernimmt ein skeleton das Packen/Entpacken der serialisierten Daten.

4. Softwareentwicklung nach Unified Process mit Wasserfallmodell vergleichen!

Das Wasserfallmodell berücksichtigt teilweise die Möglichkeit von Rückschritten. Es sieht eine Abfolge der Arbeitsschritte Anforderungen, Analyse, Entwurf, Implementierung, Test und Betrieb vor und lässt einen Rückwärtsschritt von einem Arbeitsschritt auf den direkten Vorgänger zu. Ein Arbeitsschritt kann jedoch erst abgeschlossen werden, wenn alle dafür vorgesehenen Produkte fertiggestellt worden sind. Dies soll zu einer Risikominimierung führen. Es eignet sich gut für Projekte, in denen die Arbeitsschritte deutlich voneinander getrennt werden können. Dazu müssen am Projektbeginn alle Risiken ausreichend ausgeschlossen werden. Bei großen Arbeitsgruppen ist es aufgrund der Anzahl der Mitarbeiter unmöglich, dass alle an einem Arbeitsschritt arbeiten. Hier sollte ein iteratives Modell verwendet werden.

Der Unified Process hat einige Eigenschaften, die ihn grundlegend vom Wasserfallmodell unterscheiden: Er ist Use-Case gesteuert, ein iterativer und inkrementeller Prozess und architekturzentriert. Dadurch, dass alle weiteren Phasen auf den Anwendungsfällen aufbauen, werden alle Arbeitsschritte der Softwareentwicklung in Verbindung gesetzt und sind nicht ein wasserfallartiger Prozess. Im Gegensatz zum Wasserfallmodell, wo wir eine strikt sequentielle Abfolge der Phasen haben und keine Überlappung möglich ist, ist der Unified Process iterativ und inkrementell. Nach anfänglichen Planungsschritten muss jeder Arbeitsschritt in so genannten Iterationen mehrmals durchlaufen werden. Umfang und Qualität des Produktes werden schrittweise verbessert. So viele wie notwendige Produkte werden parallel weiterentwickelt und so wächst das Projekt inkrementell. Späte Rückschläge werden so vorwiegend vermieden oder erfordern nur geringe Anpassungen im Gegensatz zum Wasserfallmodell.

Weitere Unterschiede: Beim Unified Process liegt bereits zu Beginn ein Prototyp vor, und während jeder Phase wird ein lauffähiger Prototyp hergestellt. Das Testen ist dabei stets eine begleitende Aktivität. Es gibt keine sprunghaften Phasenübergänge. Beim Wasserfallmodell liegt erst am Ende ein lauffähiger Prototyp vor, der dann getestet wird. Dadurch werden Fehler in der Analyse und im Design erst spät erkannt (late design breakage). Beim Unified Process wird das Projekt in Hinblick auf einfache Erweiterbarkeit und Wiederverwendbarkeit entworfen.

5. Begriff "Rapid Prototyping" in Softwareentwicklung erklären

Hier wird zu Beginn des Projekts ein Prototyp mit sehr eingeschränkter Funktionalität erstellt und dem Kunden zur Verfügung gestellt. Die Erstellung und Evaluierung des Rapid Prototype ersetzt die herkömmliche Analysephase. Alle weiteren Entwicklungsphasen sind wie beim Wasserfallmodell. Mit diesem Modell wird versucht, eine der Hauptschwächen des Wasserfallmodells (lauffähige Version liegt erst am Ende vor) zu beseitigen.

- Seite 2 -

Software Engineering WS01/02 Andreas Unterweger

6. Iterative und inkrementelle Vorgangsweise im Unified Process erklären! Vorteile dadurch gegenüber Wasserfallmodell

Im Unified Process wird der Softwareentwicklungsprozess zeitlich in vier Phasen unterteilt: • Konzeptualisierung, Ausarbeitung, Konstruktion, Übergang

Jede Phase wird in mehrere Iterationen unterteilt und jede Iteration mit einem Release abgeschlossen. Umfang und Qualität des Produktes werden so schrittweise gesteigert. So viele wie notwendige Produkte werden parallel weiterentwickelt und so wächst das Projekt inkrementell. Späte Rückschläge werden so vorwiegend vermieden oder erfordern nur geringe Anpassungen im Gegensatz zum Wasserfallmodell. Dies ist auch der Hauptvorteil. Weitere Vorteile: Phasen überlappend, jede Iteration mit einem Release abgeschlossen, late-design-breakage wird vermieden, einfache Erweiterbarkeit.

7. Alternative Modelle zum Wasserfallmodell

Das klassische Wasserfallmodell wurde durch einige andere Modelle adaptiert bzw. erweitert:

• Rapid-Prototyping-Modell: Zu Projektbeginn wird ein Prototyp mit sehr eingeschränkter Funktionalität erstellt und ausgeliefert. Die Erstellung und Evaluierung des Rapid Prototype ersetzt die herkömmliche Analysephase. Alle weiteren Entwicklungsphasen sind wie beim Wasserfallmodell

• Das inkrementelle Modell: Die Implementierungs- und Testphase wird durch mehrere Build-Phasen ersetzt. Jede Build-Phase besteht aus Design, Implementierung, Integration, Test und anschließendem Release. Das System wird solange erweitert, bis die Gesamtfunktionalität erreicht ist. Der Rest ist wie beim Wasserfallmodell. • Synchronize-and-Stabilize-Modell: Es ist eine Variante des inkrementellen Modells. Es gibt 3-4 Build-Phasen, an denen parallel gearbeitet wird. An sogenannten Synchronisationspunkten werden die Teilkomponenten zusammengeführt und getestet. Jede Build-Phase wird mit einer Stabilisierung abgeschlossen, um Fehler zu eliminieren. • Spiral-Modell: Es ist dem Unified Process ähnlich. Es beinhaltet eine frühe Minimierung von Risiken und eine Einteilung in Phasen. In jeder Phase existiert eine Analyse und ein Prototyp. Jeder Zyklus inkludiert eine Anforderungsanalyse, Design, Implementierung, Integration und Test. • Weitere Modelle: V-Modell, Fountain-Modell

8. Vererbungskonzepte von UML und deren Realisierung in Java beschreiben!

• „is-a“-Beziehung (Generalisierung, Spezialisierung): Sie bedeutet, dass alle Unterklassen die Eigenschaften ihrer Oberklassen erben. Objekte der Unterklassen können überall dort verwendet werden, wo Objekte der Oberklasse verwendet werden aber nicht umgekehrt.

Software Engineering WS01/02 Andreas Unterweger

In Java wird eine Spezialisierung durch das Schlüsselwort „extends“ ausgedrückt: Class Student extends Person {...} Class Professor extends Person {...}

• „part-of“-Beziehungen (Aggregation, Komposition): Assoziationsbeziehungen besagen, dass Objekte der einen Klasse mit Objekten der anderen Klasse verbunden sind. OO-Sprachen implementieren „part-of“-Beziehungen durch Instanzvariablen, die Objekte aufnehmen können. Zwischen Aggregation und Komposition wird in Java nicht explizit unterschieden (null-Objekt, falls nicht vorhanden). Für semantische Beziehungen ist die Klasse selbst verantwortlich.

• Abhängigkeitsbeziehung: Ist eine sogenannte „benutzt“-Beziehung. Sie wird in Java durch das „import“ Statement ausgedrückt.

• Realisierungsbeziehung: Sie wird in Java mittels implements ausgedrückt.

Software Engineering WS01/02 Andreas Unterweger

9. Wesentliche Bestandteile von Use-Case-Diagrammen anhand einiger Beispiele!

Use-Case-Diagramme dienen zur Visualisierung, Spezifikation und Dokumentation der Funktionalität eines Systems.

Generalisierungsbeziehung „parent use case“ generalizes „child use case“

10. Rollen der Use-Case-Modellierung im Unified Process!

Alle Phasen im Unified Process bauen auf den Anwendungsfällen auf. Sie dienen zum Erfassen und visualisieren der Systemanforderungen und zur

Geschäftsprozessmodellierung. Mit Hilfe von Use-Case-Diagrammen wird das Design-Modell erstellt und evaluiert. Sie werden als Grundlage genommen für die Definition der Testfälle im Testmodell, zur Planung von Iterationen, zur Erstellung der Benutzerhandbücher, zur Verteilung des Systems und zur Synchronisierung des Inhalts verschiedener Modelle. Jeder Use Case beschreibt eine Menge von Aktionsfolgen. Use-Case-Diagramme beschreiben das externe Verhalten eines Systems aus der Sicht der Anwender, ohne dabei auf die Realisierung einzugehen.

11. Verwendung abstrakter Klassen bzw. Interfaces in OO-Softwareentwicklung! Unterschiede der beiden in Java!

Abstrakte Klassen und Interfaces dienen als grundlegende

Wiederverwendungsmechanismen in der OO-Softwareentwicklung. Mittels Vererbung können Familien von Objekten definiert werden, die idente Interfaces haben. Dazu müssen alle entsprechenden Klassen von einer abstrakten Superklasse oder einem Interface abgeleitet werden. Klienten sind damit von den tatsächlichen Klassen der verwendeten Objekte als auch von den Klassen, die diese Objekte implementieren, unabhängig.

- Seite 5 -

Software Engineering WS01/02 Andreas Unterweger

Unterschiede der beiden in Java: Ein Interface besitzt nur eine Menge von abstrakten Methoden. Im Unterschied dazu können abstrakte Klassen auch implementierte Methoden und Variablen haben. Interfaces liegen neben der Vererbungshierarchie, währenddessen abstrakte Klassen in der Vererbungshierarchie liegen.

12. Wesentliche Komponenten von UML-Aktivitätsdiagrammen! Wozu verwendet?

Aktivitätsdiagramme modellieren dynamische Aspekte eines Systems, indem sie den Kontrollfluss von Aktivität zu Aktivität zeigen. Sie modellieren Workflows und Operationen. Sie werden meistens dazu verwendet, um den Ablauf komplexer Operationen zu erfassen oder um Use Cases bzw. das Zusammenspiel mehrerer Use Cases zu beschreiben. Sie eignen sich besonders gut zur Darstellung von sequentiellen Abläufen, die durch interne Ereignisse gesteuert werden. Es kann auch Parallelität dargestellt werden.

13. Begriffe "Kohäsion" und "Kopplung" erklären!

• Kohäsion: ist ein Maß für die interne Bindung innerhalb von Modulen. Wird durch ein Element zu viel Funktionalität verwirklicht und ist somit das Element zu generell, nimmt die Kohäsion ab, da nicht unbedingt ein Zusammenhang zwischen der Umsetzung einer Funktion und der einer anderen bestehen muss. Bei der Aufteilung des Systems in Module sollte eine hohe Kohäsion innerhalb der Module angestrebt werden. • Kopplung: Kopplung ist ein Maß für die externe Bindung zwischen Modulen, d.h. für die gegenseitige Abhängigkeit mehrerer Module. Ist eine starke Kopplung in einem System vorhanden, so müssen bei der Änderung eines Moduls meist auch andere Module geändert werden. Es sollte daher eine geringe Kopplung angestrebt werden.

Gut zu erkennen sind Kopplung und Kohäsion an Sequenz- und Kollaborationsdiagrammen (Je übersichtlicher, umso besser)

14. Drei Arten von Analyseklassen im Unified Process erklären!

Das Analysemodelldiagramm ist ein Klassendiagramm, welches das System aus einer internen (technischen) Sicht darstellt. Es soll eine Übersicht über das System geben. Es besteht aus folgenden Teilen:

• Entitäten: Sie speichern Daten, mit welchen das System arbeiten muss. Informationsklassen

Software Engineering WS01/02 Andreas Unterweger

• Schnittstelle: Modelliert die Interaktion zwischen dem System und einem Aktor

• Controller: Realisieren Steuerungs- und Koordinationsaufgaben

15. Wichtigste Qualitätskriterien für Softwareprodukte? Korrektheit und

Zuverlässigkeit erklären, Erhöhung der Zuverlässigkeit in Java?

Qualitätskriterien können je nach Blickwinkel eingeteilt werden in: • Interessenslagen: Kunde, Hersteller

• Externe Qualitätskriterien: Korrektheit, Robustheit, Zuverlässigkeit, Benutzungs-freundlichkeit, Effizienz, Wiederverwendbarkeit, Kompatibilität und Interoperabilität, Portabilität

• Interne Qualitätskriterien: Wartbarkeit, modulares Design, lesbarer Code, usw....

- Korrektheit: vollständige und fehlerfreie programmtechnische Umsetzung der vorliegenden Spezifikationen, Korrektheit nicht entscheidbar - Robustheit: Sinnvolle Reaktion des Programms auch bei fehlerhaften Eingaben - Zuverlässigkeit: Fehler sollten nur selten auftreten und nur geringe Auswirkungen haben, Schweregrade der Fehler, Existenz von Fehlern kann nicht ausgeschlossen werden, stellt ein Kriterium sowohl für die Spezifikation als auch für die Realisierung dar.

- Benutzungsfreundlichkeit: komfortable Bedienung, Hilfsfunktionen, Benutzerdokumentation

- Effizienz: „Performance“, Laufzeiteffizienz und Speichereffizienz - Wiederverwendbarkeit: Teilsysteme sollten wiederverwendbar sein, daraus kann ein System mit Komponenten von hoher Qualität entstehen - Kompatibilität und Interoperabilität: Wie einfach können unterschiedliche Softwareprodukte miteinander kombiniert werden. - Portabilität: unterschiedliche Plattformen

- Wartbarkeit: Suchen und Beheben von Fehlern, Portierung und Verbesserung der Software - Dokumentation: Benutzungsschnittstellen, Schnittstellen zu anderen

Softwaresystemen, kommentierter Quelltext, Dokumentation (des Systems, für den Benutzer)

Zur Bewertung der Produktion von Software gibt es verschiedene Ansätze: • Referenzmodell (SEI-CMM) • ISO 900X

In Java wird die Zuverlässigkeit durch das sogenannte Exception Handling erhöht. Kommt es zu einem Fehler, kann dieser abgefangen werden und das Programm kann weiterlaufen. Dies wird durch die try/catch/finally-Anweisung, die throws-clause in Methodendeklarationen und die throw-Anweisung zum Auslösen von Exceptions bewerkstelligt.

16. Begriff der Wartbarkeit erklären! Maßnahmen für möglichst gute Wartbarkeit

Das Kriterium Wartbarkeit umfasst alle inneren Eigenschaften von Software, die mit

- Seite 7 -

Software Engineering WS01/02 Andreas Unterweger

• Dem Suchen und Beheben von Fehlern

• Der Portierbarkeit • Der Verbesserung der Software zusammenhängen.

Bei der Aufteilung eines Systems in Module ist eine hohe Kohäsion und geringe Kopplung anzustreben, um den Aufwand bei der Wartung zu minimieren. Gut erkennen lässt sich Kohäsion und Kopplung an Sequenz- und Kollaborationsdiagrammen. Weiters wird die Wartbarkeit durch eine konsequent eingesetzte Entwicklungsmethodik (iterativer, inkrementeller Prozess, gute Dokumentation) sowie durch Qualitätssicherungsmaßnahmen erhöht.

17. Begriff "late design breakage" erklären! Maßnahmen zur Verhinderung im Unified Process

Unter late-design-breakage versteht man späte Rückschläge im

Softwareentwicklungsprozess aufgrund von Analysefehlern in frühen Phasen. Im Unified Process wird der Softwareentwicklungsprozess zeitlich in vier Phasen unterteilt: Konzeptualisierung, Ausarbeitung, Konstruktion, Übergang

Jede Phase wird in mehrere Iterationen unterteilt und jede Iteration mit einem Release abgeschlossen. Umfang und Qualität des Produktes werden so schrittweise gesteigert. So viele wie notwendige Produkte werden parallel weiterentwickelt und so wächst das Projekt inkrementell. Späte Rückschläge werden so vorwiegend vermieden oder erfordern nur geringe Anpassungen im Gegensatz zum Wasserfallmodell.

18. Begriff Softwarearchitektur und seine Rolle im Unified Process erklären! Welche Konzepte bietet die UML zur Architekturmodellierung an?

Der Begriff Softwarearchitektur umfasst alle Entscheidungen über die Organisation eines Softwaresystems, die wesentlichen Strukturelemente und deren Interfaces, sowie die Zusammensetzung von Struktur- und Verhaltenselementen zu größeren Teilsystemen. Es existieren 5 Sichten: • Entwurfssicht, Implementierungssicht, Prozesssicht, Einsatzsicht, Anwendungssicht

Für jede dieser Sichten können sowohl statische als auch dynamische Aspekte modelliert werden.

Der Unified Process ist architektur-zentriert: Die Beschreibung der Architektur beginnt bereits sehr früh parallel zur Beschreibung der Anwendungsfälle. Zur Bestimmung der Architektur reicht normalerweise die Berücksichtigung der wichtigsten Anwendungsfälle aus. Zunächst werden jene Teile beschrieben, die unabhängig von den Anwendungsfällen sind, bevor anschließend für die Architektur die Umsetzung der wichtigsten Anwendungsfälle in Subsystemen, Klassen und Komponenten entworfen wird. Die Architektur wird im Zuge der inkrementellen Entwicklung immer ausgereifter.

Architekturmodellierung mit UML:

Die UML stellt u.a. Komponentendiagramme (Softwarekomponenten und deren Beziehungen), Einsatzdiagramme (visualisieren die Hardwaretopologie) und das Konzept der Teilsysteme (Zusammensetzung eines Systems) zur Verfügung.

19. Hauptaufgaben der Phasen im Unified Process?

- Seite 8 -

Software Engineering WS01/02 Andreas Unterweger

Die Phasen des Unified Process sind: Konzeptualisierung, Ausarbeitung, Konstruktion und Umsetzung. • Konzeptualisierung Ziele: Umfang und Abgrenzung des Projekts ^- Erfassender wichtigsten Hauptanforderungen anhand von Use-Cases ^- Inder Konzeptualisierung wird der Kontext des Systems festgelegt und die Hauptrisiken bestimmt. Es wird die Systemarchitektur skizziert sowie die Systemgrenzen und Schnittstellen erfasst.

• Ausarbeitung Ziele:

Definition und Validierung der Systemarchitektur ^- EinProjektplan wird aufgestellt ^- Eswerden die kritischen Use-Cases beschrieben, der Entwicklungsprozess und die Entwicklungsumgebung festgelegt sowie die Systemarchitektur weiterentwickelt.

• Konstruktion Ziele:

Realisierung der vollständigen Systemfunktionalität ^- Erzeugungnutzbarer Versionen (Releases) ^- Erreichender geforderten Produktqualität ^- DieKomponenten sollen vervollständigt und getestet werden. Weiters soll die Funktionalität von Releases mit den Anforderungen verglichen werden.

• Umsetzung Ziele:

Integration des Produkts in die Umgebung des Kunden ^- Eswerden Tests, Fehlerbehebungen, Datenbankanbindungen sowie ein Training der ^- Benutzerund Administratoren durchgeführt.

20. Aktivitäten und Artefakte des Requirements Workflows im Unified Process

• Aktivitäten: Ermitteln von Akteuren und Use-Cases, Detailbeschreibung der Use-Cases, Strukturieren des Use-Case-Modells, Prototyp für User-Interface • Artefakte: Use-Case-Modell, Glossar, User-Interface Prototyp, Architekturbeschreibung • Ziele: Kurzbeschreibung der potentiellen Anforderungen, Verstehen des Systemkontexts, Ermitteln der funktionalen Anforderungen

21. Aktivitäten und Artefakte des Analyse Workflows im Unified Process

• Aktivitäten: Architekturanalyse, Analyse der Use-Cases, Analyse von (Analyse)Klassen, Analyse von Paketen • Artefakte: Analysemodell, Analyseklassen, Use-Case-Realization-Analysis, Analysepakete, Architekturbeschreibung

• Ziele: Analyse und Verfeinern der Anforderungen, Erfassen unberücksichtigter Anforderungen, Identifizieren von Analyseklassen, Erstellen eines Analysemodells

22. Aktivitäten und Artefakte des Design Workflows beschreiben!

• Aktivitäten: Architekturdesign, Use-Case-Design, Klassendesign, Teilsystemdesign • Artefakte: Designmodell, Designklassen, Use-Case-Realization-Design, Design Teilsysteme, Interfaces, Einsatzmodell, Architekturbeschreibungen • Ziele: Klassendesign, Festlegen der Systemarchitektur, Treffen der wesentlichen Implementierungsentscheidungen, Erstellen des Einsatzmodells

- Seite 9 -

Software Engineering WS01/02 Andreas Unterweger

23. Aktivitäten und Artefakte des Implementation Workflows beschreiben!

• Aktivitäten: Implementieren der Architektur, Systemintegration, Implementieren von Teilsystemen, Implementieren von Klassen, Durchführen von Unit Tests • Artefakte: Implementierungsmodell, Architekturbeschreibung, Einsatzmodell, Integrationsplan

• Ziele: Realisieren des Gesamtsystems, Implementierung der Designklassen und Teilsysteme, Testen der einzelnen Systemkomponenten

24. Aktivitäten und Artefakte des Test Workflows beschreiben!

• Aktivitäten: Testplanung, Testdesign, Testimplementierung, Durchführen von Integrationstests, Durchführen von Systemtests, Evaluieren der Tests • Artefakte: Testmodell, Testevaluierung, Testplan, Defektbeschreibung • Ziele: Evaluierung der Systemfunktionalität, Erstellen von Testplänen, Erstellen eines Testmodells, Durchführen von Komponenten-, Integrations- und Systemtests, Testevaluierung, Defektbeschreibungen

25. Grundlegende Testtechniken im Unified Process! Unterschied Black-Box, White-Box-Test!

Es gibt mehrere Testmethoden: • Unterteilung in Äquivalenzklassen (Black Box) • Grenzwertanalyse (Black Box) • Überdeckungsgrade (White Box) • Exploratives Testen • Klassenorientiertes Testen (White Box) • datenorientiertes Testen.

Black-Box-Tests ignorieren die interne Struktur des zu testenden Elements vollkommen. Die Tests werden basierend auf den in den Anwendungsfällen beschriebenen Anforderungen durchgeführt. Treten Fehler auf, kann anhand des Testfalls nur ungefähr bestimmt werden, wo der Fehler aufgetreten ist.

Für White-Box-Tests muss die logische Struktur des zu testenden Elementes bekannt sein. Bei White-Box-Tests wird versucht, aufgrund der Struktur alle möglichen Ausführungspfade zu überprüfen und mögliches Fehlverhalten bei einem der Pfade zu entdecken. Vor allem Hauptpfade und kritische Pfade sollten getestet werden.

26. Rolle von "Desing Patterns" in moderner Softwareentwicklung erklären! Welche zentralen Code-Wiederverwendungsmechanismen werden bei Patterns eingesetzt?

Ein Software-Design-Pattern (Software-Entwurfsmuster) ist die Beschreibung einer Familie von bewährten Lösungen für ein Softwaredesignproblem, das in einem bestimmten Kontext wiederholt auftritt. Designpatters repräsentieren wiederverwendbare Lösungen. Sie erfassen die statischen und dynamischen Strukturen erfolgreicher Lösungen für Probleme, die wiederholt bei der Softwareentwicklung in einem bestimmten Kontext auftreten. Patterns sind unabhängig von einer konkreten Implementierung bzw. Programmiersprache. Sie sind dabei keine Makros oder Klassenbibliotheken und auch keine Toolkits oder Frameworks. Ziele der Designpatterns ist es, die Softwarequalität und -produktivität zu erhöhen sowie die Dokumentation und Wiederverwendung von Softwarearchitekturen und Softwaredesigns zu

- Seite 10 -

Software Engineering WS01/02 Andreas Unterweger

verbessern. Die Risiken sollen so minimiert und der Automatisierungsgrad in der Softwareentwicklung erhöht werden.

Beispiele für Patterns: • Composite, Adapter, Observerpattern...

Zentrale Code-Wiederverwendungsmechanismen: siehe Frage 28

27. Vor- und Nachteile des Vererbungskonzeptes OO-Sprachen! Vererbungskonzept Javas

• Vorteile: Die Vererbung ist eine einfache Methode zur Wiederverwendung von Code, die direkt durch OO-Programmiersprachen unterstützt wird. Eine einfache Erweiterung der wiederverwendeten Implementierung ist somit möglich. • Nachteile:

Die Implementierung der Oberklasse kann nicht dynamisch geändert werden, da die ^- Vererbungein statischer Mechanismus ist.

Änderungen der Oberklasse haben somit oft Auswirkungen auf die Unterklassen, da ^- dieImplementierung der Oberklasse in den Unterklassen sichtbar ist. Implementierungsabhängigkeiten von Oberklassen mindern die ^- Wiederverwendbarkeiteiner Unterklasse.

• Vererbungskonzept Javas

Mit Hilfe des Schlüsselwortes „extends“ realisiert Java Subklassen als einfache Vererbung. Dabei können Subklassen jedoch nur eine Superklasse erweitern. Dagegen ist die Implementierung von beliebig vielen Interfaces mittels „implements“ möglich. Unterklassen erben mittels extends die Methoden und Variablen ihrer Oberklassen, können neue Methoden und Variablen definieren und können geerbte Methoden überschreiben. Weitere wichtige Konzepte: - Die Vererbung ist transitiv

- Zuweisungskompatibilität, Polymorphismus: Objekte einer Unterklasse können auf Objekte einer Oberklasse zugewiesen werden.

- Overriding: Eine Unterklasse kann Methoden einer Oberklasse überschreiben (gleiche Signatur erforderlich, bei static-final-private Methoden nicht möglich) - Overloading: Wiederverwendung des Namens für Methoden mit unterschiedlicher Signatur

Die Vererbung von Variablen und Methoden wird mittels Sichtbarkeitsattributen bewerkstelligt:

- Public, protected, private protected: Vererbung an alle Unterklassen - Private: keine Vererbung

- Default: Vererbung an alle Unterklassen desselben Pakets

28. Grundlegende Code-Wiederverwendungsmechanismen in OO-Software-Entwicklung!

• Abstrakte Klassen und Interfaces: Mittels Vererbung können Familien von Objekten definiert werden, die idente Interfaces haben. Dazu müssen alle entsprechenden Klassen von einer abstrakten Superklasse (oder Interface) abgeleitet werden. • Vererbung (statisch): Eine Unterklasse erbt die Implementierung der Oberklasse. Sie wird auch als White-Box-Reuse bezeichnet, da die internen Details der Oberklasse in der Unterklasse sichtbar sind. (+einfache Methode zur Wiederverwendung von Code, -Implementierung der Oberklasse in Unterklasse sichtbar)

- Seite 11 -

Software Engineering WS01/02 Andreas Unterweger

• Komposition (dynamisch): Nach dem Prinzip der Komposition kann komplexere Funktionalität durch Zusammensetzen mehrerer Objekte erreicht werden. Die Komposition wird auch als Black-Box-Reuse bezeichnet, da die internen Details der Objekte nicht sichtbar sind, sondern nur deren Interfaces.(+dynamischer Mechanismus, +Zugriff auf Objekte über Interface, -Vielzahl von Objekten) • Delegation (dynamisch): Eine Klasse kann die Funktionalität einer anderen Klasse wiederverwenden, indem sie Instanzen der anderen Klasse verwendet, um deren Funktionalität zur Verfügung zu stellen. (+höhere Flexibilität, als bei Vererbung, -Programme schwerer zu verstehen)

29. Abstraktion und Kapselung in OO-Softwareentwicklung und Umsetzung in Java erklären!

Abstraktion bezeichnet den Vorgang, sich auf die wesentlichen Eigenschaften von Dingen zu konzentrieren. Sie ist der fundamentale Mechanismus, um die Komplexität bei der Softwareentwicklung in den Griff zu kriegen. Das Konzept der Abstraktion trennt Implementierung und Verwendung. Dieses Konzept erlaubt es des weiteren, die Details zu ignorieren und selbst komplexe Probleme lösen zu können. Die Kapselung bedeutet, dass dem Benutzer nur jene Daten und Funktionen über eine Schnittstelle zugänglich gemacht werden sollten, die für ihn relevant sind. Alle internen Details sollten von außen nicht zugreifbar sein. Die Kapselung erhöht die Softwarewiederverwendbarkeit.

Umsetzung in Java: Für die Abstraktion und Kapselung steht das Konzept der Klasse im Mittelpunkt. Sie realisiert ein Objekt mit Variablen und Methoden. Über Sichtbarkeitsattribute (private, public, protected, private protected, default) werden Sichtbarkeitsmerkmale und Vererbung der Variablen und Methoden geregelt. Ein abstraktes Konzept kann durch deklarieren einer abstrakten Klasse (Schlüsselwort abstract) realisiert werden. Die abstrakte Klasse kann nicht instanziiert werden, liegt aber in der Vererbungshierarchie. Sie kann auch abstrakte Methoden enthalten (Methoden ohne Ausführung).

Kapselung: Es gibt keine direkten Zugriffe auf alle modifizierbaren Felder einer Klasse. Für alle modifizierbaren Felder müssen Zugriffs-Methoden (accessor methods) geschrieben werden. Die Details der internen Implementierung der Klasse werden geschützt, wodurch jederzeit eine Änderung möglich ist, ohne dass alle Anwender der Klasse ihren Code ändern müssen.

- Seite 12 -

Software Engineering WS01/02 Andreas Unterweger

Exkurs Design Patterns

• Composite Pattern: Es benützt eine abstrakte Klasse, um einfache und zusammengesetzte Komponenten einheitlich zu repräsentieren.

CompositeTest:

Software Engineering WS01/02 Andreas Unterweger

• Observer Pattern: Besteht aus vier Teilen mit den folgenden Aufgaben: Observable: Stellt ein Interface zur An- und Abmeldung von Observern zur Verfügung ^- Observer: Definiertein Interface für Objekt, die von Änderungen benachrichtigt ^- werdensollen

TemprSensor: Speichert den Zustand, der von Observern beobachtet wird; Sendet ^- eineNachricht an alle TemprObserver, falls eine Zustandsänderung eintritt TemprObserver: Implementiert das Observer-Interface und besitzt eine Referenz auf ^- TemprSensor.

TemprTest:

Software Engineering WS01/02 Andreas Unterweger

• Adapter Pattern:

CalculatorGUIAdapter: Erbt die Funktionalität von Calculator; Realisiert das Interface ^- ActionListenerund verbindet so unterschiedliche Teile der Software

• Singleton Pattern: Garantiere, dass von einer Klasse nur eine Instanz erzeugt wird und stelle einen globalen Zugriff her

Public class TestSingleton

{

public static void main(String args[]) {

Singleton s = Singleton.getInstance(); System.out.println("First reference: " + s); s = null; s = Singleton.instance(); System.out.println("\nSecond reference: " + s); } }

Programm output: Zweimal die gleiche Referenz

- Seite 15 -

Software Engineering WS01/02 Andreas Unterweger

• Factory Pattern: Definiere eine Klassenschnittstelle mit Operationen zur Erzeugung von Objekten, aber lasse Unterklassen entscheiden, welche Klassen instantiiert werden sollen. So wird die Erzeugung von Objekten an Unterklassen delegiert.

//maze -> Labyrinth

public class MazeGame {

// Create the maze. public Maze createMaze() { Maze maze = new Maze(); Room r1 = new Room(1); Room r2 = new Room(2); Door door = new Door(r1, r2); maze.addRoom(r1); maze.addRoom(r2); r1.setSide(MazeGame.North, new Wall()); r1.setSide(MazeGame.East, door); r1.setSide(MazeGame.South, new Wall()); r1.setSide(MazeGame.West, new Wall()); r2.setSide(MazeGame.North, new Wall()); r2.setSide(MazeGame.East, new Wall()); r2.setSide(MazeGame.South, new Wall()); r2.setSide(MazeGame.West, door); return maze; } }

- Seite 16 -

Software Engineering WS01/02 Andreas Unterweger

• Command Pattern:

Kapsle eine Anfrage als ein Objekt, um Klienten mit verschiedenen Anfragen zu ^- parametrisieren,Anfragen in Warteschlangen zu stellen, ein Logbuch zu führen, und das Rückgangigmachen von Operationen zu ermöglichen Oft ist es notwendig, Anfragen an Objekte zu schicken, ohne etwas über die ^- zugehörigeOperation oder das Zielobjekt zu wissen

• Strategy Pattern:

Das Strategy Pattern ermöglicht es, den Algorithmus von den ihn nutzenden Klienten ^- unabhängigzu machen

Software Engineering WS01/02 Andreas Unterweger

UML Referenz

Einteilung der UML-Diagramme:

Strukturdiagramme - statische Aspekte eines Systems Klassendiagramme ^- Objektdiagramme (Momentaufnahme) ^- Komponentendiagramme ^- Einsatzdiagramme ^- Teilsysteme ^- Verhaltensdiagramme- dynamische Aspekte eines Systems Use-Case-Diagramme ^- Sequenzdiagramme (Zeit) ^- Kollaborationsdiagramme (Organisationen) ^- Zustandsdiagramme ^- Aktivitätsdiagramme ^-

Mechanismen Stereotypen: Erweitern das Vokabular der UML ^- Eigenschaftswerte(z.B. Versionsnummern) ^- Einschränkungen(OCL - Object Constraint Language) -

- Seite 18 -

Software Engineering WS01/02 Andreas Unterweger

Use-Case-Diagramm

Sequenz-Diagramm

Software Engineering WS01/02 Andreas Unterweger

Kollaborationsdiagramm Zustandsdiagramm

Software Engineering WS01/02 Andreas Unterweger

Aktivitätsdiagramm

Klassendiagramme

Software Engineering WS01/02 Andreas Unterweger