UML, Unified Process, Design Patterns, Wasserfallmodell

1. Wesentliche Konzepte, die Plattformunabhängigkeit Javas garantieren! Vor- und Nachteile?

Java ist eine Software-only Plattform, die auf einer hardwarebasierten Plattform abläuft. Der Java-Compiler erzeugt plattformunabhängigen Bytecode anstatt Maschinencode. Dadurch kann das Java-Programm auf jeder Plattform ablaufen, die eine Java Virtual Machine implementiert. Dadurch, dass Java dynamisch und verteilt ist (Komponenten können im Internet verteilt sein, Bytecode kann über ein Netzwerk geladen werden) wird die Plattformunabhängigkeit noch erhöht.

- Vorteile: Durch die Plattformunabhängigkeit ist Java DIE Sprache für das Internet
- Nachteile: Eine JVM muss überall implementiert sein; Performanceverlust wegen Bytecode anstatt Maschinencode: deshalb für Echtzeitanwendungen nur bedingt geeignet.

2. „Zuweisungskompatibilät“ und „Dynamic Binding“ anhand von Java-Beispielen erklären!

- Zuweisungskompatibilät: Polymorphismus bezeichnet die Fähigkeit von Objektvariablen, Objekte unterschiedlicher Klassen aufzunehmen. Dies beschränkt sich allerdings auf Objekte derselben Klasse oder einer daraus abgeleiteten Klasse.

Abbildung in dieser Leseprobe nicht enthalten p=s; //legal; jeder Student ist eine Person s=p; //illegal; nicht jede Person ist ein Student

- Dynamic Binding: OO-Programmiersprachen erlauben das Überlagern von Methoden in abgeleiteten Klassen, d.h. da eine Objektvariable X auch Objekte aus allen aus X abgeleiteten Klassen aufnehmen kann, könnte eine Funktion f in einer dieser nachgelagerten Klassen überlagert worden sein. Welche konkrete Methode also aufgerufen werden muss, kann damit erst zur Laufzeit entschieden werden.

Abbildung in dieser Leseprobe nicht enthalten

Die show-Methode von A wird durch die show-Methode von B überschrieben. Welche der beiden aufgerufen wird, entscheidet sich erst zur Laufzeit.

3. RMI-Mechanismus in Java erklären! RMI-basierte Client-Server-Anwendung mit Klassendiagramm modellieren!

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

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.

Abbildung in dieser Leseprobe nicht enthalten Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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

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

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten

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.

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.

Abbildung in dieser Leseprobe nicht enthalten

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

Abbildung in dieser Leseprobe nicht enthalten