MEP SS 08 - ThomasGalliker.ch · Der Zeitplan Ihres Projektes ist recht eng. Sie stehen also unter...

12.01.2009 1 Jousi B. Marti

Softwarekomponenten

MEP SS 08

Aufgabe 1

Nutzung einer Komponentenarchitektur in einem Projekt

Situation: Eine Anforderung in Ihrem Projekt wäre gewesen, eine Komponentenarchitektur

einzubinden.

• Wo hätten Sie diese Anforderung festgehalten?

• In welcher Projektphase hätten Sie verschiedene Komponentenarchitekturen evaluiert?

• Wo (in welchem Dokument) hätten Sie die Evaluationskriterien festgehalten? Wo die

Evaluationsergebnisse?

• Angenommen, Sie wissen nicht, ob verschiedene Komponentenarchitekturen Ihre

Anforderungen erfüllen können. Sie enschteiden sich, Prototypen zur Überprüfung zu

entwickeln. Welche Projektphasens ind davon betroffen?

• Skizzieren Sie, wie Sie die Erstellung von Prototypen planen und durchführen würden.

Könnten Sie dies auf die Hauptaktivitäten des Software Engineering abbilden?

Musterlösung:

• Anforderungsdokument

• Ausarbeitungsphase (in Systemspezifikation festgehalten)

• Evaluationskriterien � Anforderungsdokument

Evaluationsergebnisse �Systemspezifikation

• Ausarbeitungsphase, evtl. Konstruktionsphase (iterativ)

• Iteration, Am Schluss der Iteration überprüfen ob mit diesem Prototyp möglich (Review)

Ja, mit den Iterationen der verschiedenen Phasen


Aufgabe 2

Refactoring mit CORBA

Wichtige Information: In CORBA gibt es einen Event-Dienst, der es einem Server ermöglicht, Kontakt

zu den Clients aufzunehmen.

Situation: Sie haben aktuell einige wichtige Meilensteine erreicht. Nun wird die Entscheidung

getroffen, dass die Kommunikation durch CORBA unterstützt werden soll. (->Refactoring)

• Was gewinnen Sie durch die Verwendung des CORBA Namensdienstes im Vergleich zu Ihrer

aktuellen Implementation des Message Loggers?

• Welche Komponenten / Klassen wären durch das Refactoring betroffen? Warum?

• Beschreiben Sie, wie Sie vorgehen würden, um die Kommunikation umzusetzen.

• Gibt es Elemente Ihrer Implementation, die durch die Verwendung von CORBA überflüssig

würden?

Musterlösung:

• Die Austauschbarkeit mit anderen Message Logger wird einfacher, da alle dasselbe IDL

verwenden und die Implementation unabhängig wird. Es müssen nur Einstellungen gemacht

werden. Bei der bisherigen Version müsste mit grosser Wahrscheinlichkeit der Code

angepasst werden.

• Die Komponenten Test-Client, der Server und das bisherige Interface wird komplett ersetzt

(� neu IDL). � neue Kommunikation zwischen Client und Server mit CORBA.

• - Zuerst sicherstellen, dass stabile Testsuite zur Verfügung steht (automatisiert)

- Software testen

- Refactoring durchführen

- Software wieder testen

- erst dann neue Funktionen ergänzen und wieder testen

• Das Messageloggerinterface � wird durch generierte Dateien vom IDL ersetzt


Aufgabe 3

make or buy

Situation: Sie müssen eine verteilte Anwendung (Client / Server) implementieren. Sie haben die

Erfahrung aus dem Projekt Message Logger und wissen, dass es Komponentenarchitekturen gibt (z.B.

CORBA) und was diese für Sie tun können. Sie haben bisher jedoch noch keine praktischen

Erfahrungen mit Komponentenarchitekturen sammeln können.

Der Zeitplan Ihres Projektes ist recht eng. Sie stehen also unter Zeitdruck.

Sie müssen sich nun entscheiden, ob Sie Ihre Anwendung komplett selber erstellen wollen, oder ob

Sie eine Komponentenarchitektur verwenden werden.

• Nennen Sie die drei Arten von Komponentenarchitekturen

• Nennen Sie mind. 2 Argumente für jeden Entscheid

• Für was würden Sie persönlich sich entscheiden? Warum?

Musterlösung:

• RPC (Remote Procedure Call): Semantik von Prozeduraufrufen, bei Client wie lokale Funktion

RMI (Remote Methode Invocation): Java, Prinzip des RPC, kein IDL � verwendet Java

Interface

MOM: (Message Oriented Middleware): Kommunikation über Nachrichten in Queue, keine

direkte Verbindung, Client/Server nicht gleichzeitig aktiv

CORBA (Common Object Request Broker Architecture): IDL, sprachunabhängig, ORB (Object

Request Broker) ermöglicht Kommunikation zwischen Objekten,

• RPC: schnell, synchrone Kommunikation, direkte Verbindung

MOM: stabile, robuste Produkte, vielseitig einsetzbar, Kommunikationspartner muss nicht

erreichbar sein

CORBA: unterstützt durch viele Firmen (OMG), sprachunabhängig, selbstbeschreibendes

System

• CORBA: bereits etwas Erfahrung, durch viele Firmen unterstützt, sprachunabhängig


Aufgabe 4

Synchrone und Asynchrone Kommunikation

• Nennen Sie jeweils die Metapher für synchrone und asynchrone Kommunikation.

• Welche Art der Kommunikation haben Sie in Ihrem Message Logger implementiert? Wie

haben Sie sie implementiert?

• Für welche Art von Anwendungen ist diese Kommunikation sinnvoll?

• Beschreiben Sie einen Anwendungsfall für die andere Art der Kommunikation. Wie hätten Sie

diese implementiert?

Musterlösung:

• Synchrone Kommunikation: Telefon

asynchrone Kommunikation: Brief

• Synchrone, da der Client nur loggen kann, wenn der Server gestartet ist. (keine Queue)

mit CORBA, beim Senden einer Nachricht erhält der Client eine Meldung, wenn es nicht

funktioniert hat.

• Wenn direkt eine Antwort gebraucht wird, schnelle Antwortzeiten, Server „immer“

erreichbar

• Messages auch absetzen können, wenn Server nicht gestartet: eine Queue im Client, wird

periodisch geprüft ob Server erreichbar und dann alle Messages geschickt.


Aufgabe 5

Komponentenbegriff

Sie haben die Doku Ihres Teams zur Verfügung:

• Was ist eine SW Komponente?

• Wo sieht man die Aufteilung des Systems in Komponenten? Erklären Sie diese.

• Wie ist diese Aufteilung entstanden? Was waren die Kriterien? Gäbe es Alternativen?

• Woraus sollte eine Komponenten-Spezifiktaion bestehen?

• Wo (in welchem Dokument) suchen Sie die Spezifikation der einzelnen Komponenten?

• In welchen weiteren HTAgil Dokumenten reflektiert sich die Organisation Ihrer Software in

Komponenten?

Musterlösung:

• Eine Software-Komponente ist ein Software-Element, das zu einem bestimmten

Komponentenmodell passt und entsprechen einem Composition Standard ohne Änderungen

mit anderen Komponenten verknüpft und ausgeführt werden kann

• Bei der Projektplanung, 4 Arten:

- Hardware Strukturierung: Hardware-Grenzen

- Fachliche Strukturierung: funktional oder datenorientiert (Businessanwendungen)

- Technologische Strukturierung: GUI, Kommunikation, Datenverarbeitung, Persistenz

- Topologische Strukturierung: verteilte Systeme (Client/Server)

• Es werden ähnliche Sachen zusammengenommen und je nach Produkt anders strukturiert

Kriterien: HW, fachlich, technologisch, topologisch

Alternativen: prozessorientiert

• Export (angebotene Schnittstellen), Import (benötigte/benutzte Schnittstellen), Verhalten,

Kontext (Rahmenbedingungen im Betrieb der Komponente)

• Systemspezifikation UML-Komponentendiagramm (benötigte und angebotene Schnittstellen)

• Testplan (Integrationstests, etc.), Kundenanforderung, evtl. Projektplan


Aufgabe 6

Kofigurationsmanagement


• Was versteht man unter einem ConfigurationItem?

• Wo (in welchem Ihrer Dokumente) ist das Konfigurationsmanagement beschreiben?

• Ist Ihre Auflistung der ConfigurationItems vollständig? Was fehlt? Gäbe es Alternativen?

• Erklären Sie an Ihrem Projekt den Unterschied zwischen einem Release und einer Revision.

• In welchen weiteren HTAgil Dokumenten reflektiert sich die Struktur der Konfiguration Ihrer

Software?

Musterlösung:

• Ein Artefakt, das Gegenstand des CfgMgmt ist und nicht weiter aufgeteilt wird (z.B. java File)

• Im Projektplan

• Nein (Keine Auflistung) fehlt: Beschreibung was hineinkommt (Dokumente, Code),

Alternativen: alles Auflisten was dazugehört

• Release: getestete und freigegebene Baseline (Satz von Revisionen) � in Subversion,

Testplan

Revision: neue Version eines Artefaktes � Wenn neue Version einer Klasse auf Subversion

• Systemspezifikation � für jedes Release eine Version

evtl. Testplan(welche Version wurde getestet)


Aufgabe 7

Schnittstellen


• Was versteht man unter der Breite einer Schnittstelle?

• Finden Sie in Ihrer Dokumentation eine Schnittstellenbeschreibung und erklären Sie diese

• Hätten Sie die Schnittstelle anders legen können? Konsequenzen?

• Finden Sie in Ihrem Code die entsprechende Schnittstelle und erklären Sie diese

• Nennen Sie am Beispiel Ihrers Codes mögliche Änderungen und zeigen Sie die Konsequenzen

für die Breite der Schnittstelle auf.

Musterlösung:

• Anzahl und Komplexität der Parameter sowie Abhängigkeiten vom Zustand

• Systemspezifikation (Keine), IDL Schnittstelle beschreiben (sendMessage,

setForwardingFilter, getForwardingFilter)

• Nein, da vom Interface-Komitee vorgegeben, Austauschbarkeit nicht mehr vorhanden

• LoggerImpl.java wird überschrieben in G5_messagerlogger_serverView.java

• Mögliche Änderungen: zusätzliche Funktionen (können andere Clients nicht nutzen), wird

breiter


Aufgabe 8

Reviews


• Worin besteht der Nutzen einer Review?

• Was haben Sie in Ihrem Projektteam reviewed? Inwiefern war das eine gute Wahl?

• Zeigen Sie am Review-Protokoll auf, was Sie bei der Review gefunden haben und was Sie

daraus gemacht haben

• Erläutern Sie die Elemente eines Review-Protokolls

• Welche Art von Review war das? Nennen Sie andere Formen. Wann würden Sie diese

anwenden?

Musterlösung:

• Mögliche Fehler früh erkennen, Qualität verbessern, externe Sicht, oft bei Meilensteinen

• Komponentenarchitektur (UML-Diagramm), Testplan, Risikoliste: kein Code � weniger

Aufwand für anderes Team, wird eher richtig gemacht

• Mehr PM Risiken eingeführt, Systemspezifikation �UML-Diagramm geändert, Testplan

genauer � Umgebung

• Wann, Wo, Wer, Was, Unterlagen, Empfehlung, Zusammenfassung, Beilagen, Rollen,

Befunde

• PeerReview, andere Formen: Ad Hoc Review, Passaround, Pair Programming, Walkthrough,

Team Review, Inspektion


Aufgabe 9

Modularisierung


• Welche Kriterien zur Modularisierung kennen Sie? Erklären Sie eines davon.

• Zeigen Sie anhand Ihrer Dokumentation, wie Ihre Software modularisiert ist.

• Diskutieren Sie die Kriterien zur Modularisierung an Ihrer Software Struktur.

• Erläutern Sie die Modularisierungsprinzipien Kopplung und Kohäsion.

• Nehmen Sie eine Klasse aus Ihrem Code und zeigen Sie daran Kopplung und Kohäsion.

Musterlösung:

• Zerlegbarkeit (Teilprobleme unabhängig voneinander entwerfbar), Kombinierbarkeit,

Verständlichkeit (Module unabhängig voneinander zu verstehen), Stetigkeit

• Anhand Komponenten + zusätzliche (Message, Filter, Database)

• Message: Stetigkeit +, Kombinierbarkeit +/-, Verständlichkeit +, Stetigkeit –

• Kopplung: Kommunikation zwischen Modulen �minimieren

Kohäsion: interner Zusammenhalt eines Moduls � maximieren

• Message: Kopplung (String, Date, Timezone, Calendar) Kohäsion (nur getter, toString,

Konstruktor)

12.01.2009 10 Jousi B. Marti

Aufgabe 10

Projektplanung

• Worin liegt der Nutzen einer Planung (was kann sie leisten? Was nicht?)

• Erklären Sie den Begriff rollende Planung.

• Wie wird rollende Planung in HTAgil sichtbar? Erläutern Sie die grundlegenden Elemente.

• Beschreiben Sie das Vorgehen bei der Iterationsplanung gemäss HTAgil

• Zeigen Sie anhand Ihrer Dokumentation, wie Sie bei der Planung vorgegangen sind.

Musterlösung:

• Hilft Überblick zu behalten, Risiko einer Fehlentwicklung minimieren, Lieferobjekte bei jeder

Phase sind klar

Was nicht: ist zusätzlicher Aufwand, braucht man nicht mehr wenn Produkt fertig

• Makrozyklen: Projektaufgaben auf Rahmenplan abgebildet, etwa zur Halbzeit ein Prototyp

Mikrozyklen: z.B. je 2 Wochen, Tasklist erstellen, dass in der Hälfte die kritischen Elemente

stehen

• Durch das Anpassen der Planung bei den Iterationen (Meilensteine)

• Sie beginnt bei der Ausarbeitung, nach jeder Iteration ist ein lauffähiges Programm

vorhanden, am Ende der Iteration werden die geforderten Artefakte über prüft und fliessen

in die nächste Iteration ein, jede Iteration wird geprüft

• 2 Iterationen (Prototyp und CORBA Refactoring), beide mit Test

12.01.2009 11 Jousi B. Marti

Aufgabe 11

Refactoring


• Was versteht man unter Refactoring?

• Was ist die Voraussetzung für Refactoring?

• Es gibt eine Reihe von standard Refactoring Tätigkeiten. Welche kennen Sie? Erläutern Sie

eine.

• Wann (bei welcher Gelegenheit, aus welchem Anlass) würden Sie Ihre Software refactorn.

• Wo und wie reflektiert sich ein Refactoring in der Dokumentation.

Musterlösung:

• Überarbeiten der inneren Struktur, ohne das sichtbare Verhalten der SW zu verändern.

• Automatisierte Testsuite, Tests durchgeführt

• Rename (Umbenennen von Variablen, privaten/öffentlichen Methoden, etc.)

Extract Method (Extrahieren Statementblock ein neue Methode)

Inline Method (Gegenteil con Extract Method � Methode gelöscht)

Exract Superclass (aus bestehender Klasse Superklasse extrahieren� Vererbung)

• Bei Erweiterung des Codes (Struktur verbessern)

Bei der Korrektur von Fehlern (Fehler schneller finden)

Bei Code-Review (bessere Verständlichkeit für andere)

kontinuierlich

• Bei der Systemspezifikation � Verständlichkeit, Wartbarkeit, Erweiterbarkeit wird verbessert

12.01.2009 12 Jousi B. Marti

Aufgabe 12

Entwurfsmuster/Design Pattern und Software Engineering

• Welche drei Kategorien von Designpatterns kennen Sie?

• In welcher Projektphase/ in welchen Projektphasen werden Entscheidungen über die

Verwendung von Entwurfsmustern getroffen?

• Wo werden soche Entscheidungen dokumentiert?

• Stellen Sie einen Zusammenhang zw. Entwurfsmustern und Wiederverwendung her.

• In der Vorlesung haben Sie folgenden Satz gehört. „besser kein Muster einsetzen, als das

Falsche!“

Erläutern Sie!

Auf was müssen Sie achten, wenn Sie Entwurfsmsuter einsetzen wollen?

Musterlösung:

• Erzeugungsmuster, Strukturmuster, Verhaltensmuster.

• Fast in allen (ausser Transition), mehrheitlich aber in der Konstruktionsphase

• im Klassendiagramm in der Systemspezifikation

• Entwurfsmuster sind eine (sehr) effektive Form von Wiederverwendung des Designs!

• Falsche Muster machen eine SW schwerer Verständlich, Wartbar und Erweiterbar

Sinvolle Auswahl, anhand von Kriterien: Verständlichkeit, Aufwand, Notizen etc.

12.01.2009 13 Jousi B. Marti

Aufgabe 13

Entwurfsmsuter/Design Pattern konkret

• Welches Ziel/Aufgabe verfolgen Sie mit Erzeugungsmustern?

• Welches ist das wohl bekannteste Erzeugungsmuster?

• Welches Ziel/Aufgabe verfolgen Sie mit Strukturmustern?

• Welches Ziel/Aufgabe verfolgen Sie mit Verhaltensmustern?

• Erklären Sie den Sinn des Fassaden Patterns

• In welche Kategorie gehört das Strategie Muster?

• Erklären Sie das Strategiemuster!

Musterlösung (nur ein Teil)

• Die Erstellung (und ggf Verwaltung) von Objekten, generalisieren, abstrahieren,

vereinheitlichen, Gewaltentrennung zwischen Objektbezieher und Entscheidung welches

Objekt gebraucht wird

• Singleton

• Fassen Objekte (oder Klassen) zu grösseren oder veränderten Strukturen zusammen,

unterschiedliche Strukturen einander anpassen und verbinden

• Beschreiben Interaktion zwischen Objekten (Kontrollflüsse, Zuständigkeit)

• Stellt einheitliche, zusammengefasste Schnittstelle zu einer Menge von Schnittstellen eines

Subsystems zur Verfügung

• Verhaltensmuster, objektbasiert

• unterschiedliche Varianten von Algorithmen zur Verfügung stellen

austauschbar machen, Algorithmus unabhängig von Klient

Strategie: Abstrakt, Schnittstelle anbieten

Konkrete Strategie: implementiert konkreten Algorithmus

Kontext: besitzt Referenz auf Strategie, mit Strategie konfiguriert

12.01.2009 14 Jousi B. Marti

Aufgabe 14 Entwurfsmsuter/Design Pattern und das Message Logger Projekt

1. Haben Sie in Ihrem Projekt ein oder mehrere Entwurfsmuster verwendet?

Falls ja:

Skizzieren Sie das verwendete Entwurfsmsuter!

Skizzieren Sie den Einsatz des Entwurfsmusters in Ihrem Projekt.

Begründen Sie die Wahl des Entwurfsmsuters für Ihr Projekt

Falls nein:

Gibt es ein Entwurfsmuster, das Sie einsetzten würden, wenn Sie Ihr Projekt noch

einmal starten würden? Wenn ja welches und warum, wenn nein warum nicht?

Nehmen Sie an, der Auftrag fü den Message Logger hätte auch die Nutzung von Entwurfsmustern

umfasst.

2. Wann hätten Sie Entwurfsmuster evaluiert?

3. Nennen Sie einige mögliche Krierien, die Sie bei dieser Evaluation hinzugezogen hätten.

Musterlösung:

• Ja, Adapter

Einsatz vor allem in 1. Iteration:

beim Server, bei der Verbindung von Clients und Viewer zum Server (SocketAdapter und

Server), beide Verbindung gleich, jedoch andere Funktionaliät

• Hauptsächlich in der Ausarbeitungsphase, jedoch auch in der Konstruktion möglich

• Einfachere Verwaltung, bessere Effizienz, Event-Handling

12.01.2009 15 Jousi B. Marti

Aufgabe 15

Testen und Software Engineering

1. In welchen Software Engineering Phasen müssen Sie das Testen der Software „im Auge

haben“?

Sie haben in der Vorlesung zwei Arten von Tests (Unit Test oder Systemtest) besprochen.

2. Wählen Sie eine der Testarten aus.

Beschreiben Sie sie

Erklären Sie, in welchen Phasen diese Testart im Softwareengineering eine Rolle spielt.

3. In welchen Dokumenten halten Sie Elemente fest, die (auch im weiteren Sinne) mit dieser

Testart zusammenhängen? Skizzierne Sie die Information. Wei hängt sie mit dem Test

zusammen?

Musterlösung:

• Kontinuierlich: Ausarbeitung, Konstruktion, Übergang

• Unit-Test: funktionaler Test von einzelnen, in sich abgeschlossenen Units (Klassen, Modul)

Automatisiert, schnell und einfach ausführbar, in IDE gemacht

Phase: in Konstruktionsphase integriert

• Testplan �was wird wie getestet, Testprotokoll � Testergebnisse, mehrere Durchläufe

12.01.2009 16 Jousi B. Marti

Aufgabe 16

Testen allgemein

1. Wo liegen die Herausforderungen beim Testen von SW?

2. Erklären Sie den Unterschied zwischen Unit-Tests und Systemtests?

3. Wo liegen die speziellen Herausforderungen bei der Implementation von Unit-Tests

4. Worauf achten Sie speziell, wenn Sie eine Funktion testen

Beispiel: long addition (int sum1, int sum2);

5. Welche Möglichkeiten bietet Ihnen die Messung der Codeabdeckung?

Musterlösung:

• Viele mögliche antworten: z.B. Effizientes Testen, d.h. mit minimalem Aufwand maximale

Testresultate. Oder generelle (in-)Akzeptanz vom Bedarf nach (spez. Automatisierten) Tests,

Kostendruck- es wird zuerst beim Testen gespart. Vermeintliche Unattraktivität des Testens

etc.

• Unit-Test: funktionaler Test von einzelnen, in sich abgeschlossenen Units

Systemtests: gesamtes System auf Basis der Spezifikation, explizit geplant

• Qualität und Nachvollziehbarkeit ist wichtig, GUI schwierig testbar, oft hier gespart

• Normalfälle, Grenzfälle (z.B. grösstmögliche Zahl) und Ausnahmefälle (z.B. ungültige Zeichen)

testen

• Während der Ausführung der Test wird von Laufzeitumgebung gemessen, welche Statements

abgearbeitet wurden � statistische Aufbereitung

12.01.2009 17 Jousi B. Marti

Aufgabe 17

Testen und das Message Logger Projekt

1. Welche Vorteile bringt der Einsatz des „Test-First“ – Konzeptes?

2. Beschreiben Sie, wie Sie das Test-First Konzept in Ihrem Projekt umgesetzt hätten.

3. Beschreiben Sie / geben Sie Beispiele für Klassen, welche sich relativ einfach und gut mit

(J)Unittests prüfen lassen.

4. Nennen Sie Beispiele für solche Klassen in Ihrem Projekt. Begründen Sie!

5. Bewerten Sie kurz das Testen in Ihrem eigenen Projekt. Was haben Sie gut gemacht?

Warum? Was würden Sie in Zukunft anders machen? Warum?

Musterlösung (nur ein Teil)

1. Genaueres Studium (- besserer) Entwurf der Schnittstelle im Vorfeld, wenn fertig schon

getestet werden

2. Zuerst geeignete Klasse gesucht, Unit-Tests geschrieben, Klasse implementiert, Unit-Tests

ausgeführt

3. Rechner, klassen ohne GUI, klassen mit geringer Kopplung und grosser Kohäsion

4. Message, Filter, Database � kein GUI, geringe Kopplung

5. Gut: Unit und Systemtests durchgeführt und protokolliert

Anders: Test-First Ansatz probieren, mehr Grenzfälle und Ausnahmefälle testen mit Unit-

Tests

12.01.2009 18 Jousi B. Marti

Aufgabe 18

Deployment

Sie geben uns als Auftraggebern des Message Loggers Ihr Projekt ab.

Wir erhalten:

den Code auf einem USB Stick sowie

die Deployment Spezifikation

Beschreiben Sie allgemein, was in einer Deployment Spezifikation festgehalten wird.

Beschreiben Sie uns, was in der Deployment Spezifikation zu Ihrem Message Logger Projekt steht /

stehen sollte.

Musterlösung:

1. Deployment Diagramme: Zuordnung der Software Laufzeit-Elemente zur Hardware (Nodes &

Artefacts) Abhängigkeiten unter den Software Artefakten

2. Deployment Spec <<manifest>>: zusätzliche Angaben über die Konstruktion einer

Einsatzkonfiguration:

installieren (Source, Binaries, Executables), konfigurieren, hochfahren eines Software-

Systems, Deinstallation

Aufgabe 19 Software Qualität

Beschreiben Sie Software-Qualität und nennen Sie mindestens 5 Kriterien für Software-Qualität.

Bewerten Sie die Software-Qualität Ihres MessageLogger-Projekts. Wählen Sie hierfür je ein Kriterium

aus

aus der Sicht des Anwenders

aus der Sicht des Entwicklers

Musterlösung:

1. In SWEBOK wird Qualität als die Menge aller Eigenschaften der Software in Bezug auf die

Erfüllung expliziter und impliziter Anforderungen umschrieben. (siehe Punkt 2 und 3)

2. Nutzersicht: Funktionserfüllung, Effizienz, Zuverlässigkeit, Benutzbarkeit, Sicherheit

3. Entwicklersicht: Erweiterbarkeit, Wartbarkeit, Übertragbarkeit, Wiederverwendbarkeit

12.01.2009 19 Jousi B. Marti

Aufgabe 20 Dokumentation von Komponenten

1. Nennen Sie wesentliche Anforderungen an die Dokumentation von Komponenten.

2. Das Interface-Kommitee hat das Interface des MessageLoggers definiert und in einem

Dokument beschrieben.

Welche Anforderungen an die Dokumentation von Komponenten waren erfüllt? Welche

nicht?

3. Wie waren die Erfahrungen in Ihrem Projektteam mit der Dokumentation? War diese

ausreichend? Was war gut? Was müsste verbessert werden?

Musterlösung:

1. Die Spezifikation einer Komponente umfasst:

o Export: unterstützte Interfaces, die andere Komponenten nutzen können.

o Import: benötigte benutzte Interfaces ovn anderen Komponenten.

o Verhalten: Verhalten der Komponente

o Kontext: Rahmenbedingungn im Betrieb der Komponente.

Nach Betrand Meyer (Design by Contract)

o Voraussetzungen – was vorher erfüllt sein muss

o Ergebniszusicherung – was nachher erfüllt ist

2. Export, Import, Verhalten (Sequenzdiagramm), Rahmenbedingung bei Nutzung

beschrieben (etwas knapp)

3. Musste immer wieder motiviert werden, Systemspezifikation und Projektplan etwas

knapp, Anforderungen gut. Systemspezifikation genauer

12.01.2009 20 Jousi B. Marti

Aufgabe 21

HTAgil Systemspezifikation

1. Nennen Sie wesentliche Inhalte (Kapitel) einer Systemspezifikation nach HTAgil.

2. Wie gehen Sie idealerweise vor, wenn Sie die Systemspezifikation erarbeiten (erarbeiten Sie

z.B. die Kapitel der Reihe nach)?

3. Die Architektur eines Systems kann mittels verschiedenster Sichten (views) dokumentiert

werden. Nennen Sie drei Sichten und erläutern Sie eine.

4. Wo und wie beschreiben Sie die Systemgrenzen? Was ist der Nutzen einer solchen

Beschreibung?

Musterlösung:

1. Systemübersicht, Kontext

Modelle (Analysemodell – Architekturmodell [div. Views] – Datenmodell

Spezifikation externe Schnittstellen

Softwareanforderungen (funktionale und nicht funktionale)

Environment Anforderungen (HW, BS, VM)

2. Die Verfeinerung der Anforderungen und der Architektur erfolgt „Hand in Hand“

Beim Architekturentwurf gibt es einen Entwurfszyklus: Analyse – Modellbildung –

Konzeptüberprüfung

3. Funktionale Sicht, Entwicklungssicht, Verteilungs- und Betriebssicht

Entwicklungssicht: Beschreibung der statischen Modul-Strukturen (meist Klassen und

Paketdiagramme)

4. In der Systemspezifikation mit Use-Case-Diagramm

Nutzen: klare Abgrenzung der Software/Schnittstellen zu z.B. Drittsystemen

12.01.2009 21 Jousi B. Marti

Aufgabe 22

HTAgil Vorgehensmodell(siehe Bild auf dem Pubwiki)

1. Zu welcher Kategorie von Vorgehensmodellen gehört HTAgil?

2. Erklären Sie diese Begriffe (inkrementell und iterativ)

3. Nennen Sie die Phasen eines solchen Vorgehensmodells der Reihe nach. Auf welcher Achse

werden die Phasen im HTAgil dargestellt?

4. Was wird auf der anderen Achse dargestellt? Erklären Sie die unterschiedlichen Formen der

Flächen.

Musterlösung:

1. Inkrementell und iterativ

2. Inkrementell: Die Releases erhalten mit jeder Iteration einen grösseren Funktionsumfang

Iterativ: Die Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen

3. Position: oben horizontal

Vorbereitung, Ausarbeitung, Konstruktion, Übergang

4. Links vertikal: Hauptdisziplinen

Kundenanforderungen, Systemspezifikation, Realisierung, Test, Verteilung und Einsatz

12.01.2009 22 Jousi B. Marti

Aufgabe 23

Planen und Schätzen

1. „Plans are nothing – planning is everything“ Was bedeutet dieses Zitat von Eisenhower?

2. Wie gehen Sie vor, wenn Sie eine Projektterminplanung machen müssen.

3. Schätzungen sind nie exakt – was machen Sie, um die Qualität der Schätzungen zu

verbessern?

4. Welche Grössenordnungen von Schätzfehlern erwarten Sie in verschiedenen Phasen des

Projektes nach oben bzw. unten?

Musterlösung:

1. Pläne gelten normalerweise nicht Lange, aber der Planungsprozess bringt die nötigen

Einsichten in das, was zu tun ist, Abhängigkeiten etc, dadurch lässt sich das Projekt steuern.

2. 1. Grobterminplanung (Rahmenplan: Meilensteine von hinten)

2. Arbeitsplanung:

o Aufgabe in Teilaufgaben (HW / fachlich / technologisch / topologisch) und

Arbeitspakete runterbrechen

o Personen zuordnen und Aufwand schätzen ( verschiedene Personen, Experten)

o Projektaufgaben in den Rahmenplan einordnen (parallel zeitversetzt sequentiell)

o Ausarbeitung in zwei Makrozyklen mit Prototyp zur Halbzeit planen.

o Innerhalb des Makrozyklus Mikrozyklen von ca 2 Wochen vorsehen.

3. Iterationsplanung für die Mikrozyklen (Tasklist rollend)

4. An den Meilensteinen die Gesamtplanung nachführen

3. Mehrere (mind. 3) Personen beteiligen (für jedes Gebiet Experte fragen)

Unterschiede diskutieren

Erfahrung aus früheren Projekten mit einbeziehen

Selber immer zuerst schätzen und am Schluss IST- und SOLL vergleichen

4. Anfang x4 - /4 später X2.../2, in der Konstruktionsphase nur noch Faktor 1.2

12.01.2009 23 Jousi B. Marti

Aufgabe 24

Reviews

1. Wann im Projektverlauf machen Sie Reviews?

2. Benennen Sie zwei dieser Reviews und geben Sie an, was deren Inhalt ist.

3. Es gibt bezüglich Formalisierungsgrad und Struktur ganz unterschiedliche Review-Arten.

Nennen Sie vier Review-Arten und charakterisieren Sie diese.

Musterlösung:

1. Typischerweise an Meilensteinen, d.h. an Stellen, wo definierte messbare Deliverables

vorliegen.

2. Feasibility Review ( Systemabgrenzung & grober Projektplan)

Requirements Review (Kundenanforderungen & Abnahmeplanung)

Preliminary Design Review (Detailentwürfe & UnitTest Spezifikation)

3. Inspection (rigorous well-defined process)

Team Review (planned and structured a bit less formal)

Pair Programming (2 Entwickler arbeiten zur gleichen Zeit am gleichen Produkt)

Ad Hoc Review (natural part of team collaboration)

12.01.2009 24 Jousi B. Marti

Aufgabe 25

Modularisierung und Komponenten

Die zentralen Erkenntnisse zur Modularisierung von Softwaresystemen wurde in den 70er Jahren von

David L Parnas erarbeitet. Seine herausragenden Arbeiten gehören bis heute zu den Grundpfeilern

des Software Engineering.

We propose that one begins with a list of design decisions which are difficult or likely to

change. Each module is then designed to hide such a design decisions from the others.

Decomposition was made using information hiding as a criterion.

(D L Parnas On the Criteria to Be Used in Decomposing Systems into Modules.

Communications of the ACM, December 1972)

1. Was bedeutet Information Hiding, und was ist der Nutzen davon?

2. Nennen Sie ein Beispiel für eine Entwurfsentscheidung im Parnas’schen Sinn.

3. Diskutieren Sie, inwiefern Komponenten in diesem Zusammenhang „gute“ Module sind.

Musterlösung:

1. Modul ist nach aussen nur über seine Schnittstelle bekannt

- Implementierung kann geändert werden ohne Probleme, solange Schnittstelle gleich

- bessere Übersichtlichkeit

- bessere Testbarkeit

2. Modularer Entwurf � abstrakte Datentypen, Bibliotheken

3. Komponente hat auch definierte Schnittstellen, kann aber auch Schnittstellen benötigen,

Komponente braucht auch Information Hiding

12.01.2009 25 Jousi B. Marti

Aufgabe 26

Komponentenarchitekturen

1. Nennen Sie die drei Arten von Komponentenarchitekturen.

2. Erklären Sie die wesentlichen Merkmale, Prinzipien und Eigenschaften dieser drei

Architekturen

3. Welche Komponentenarchitektur würden Sie bei einem Refactoring Ihres MessageLoggers

einsetzen? Wieso?

Musterlösung:

1. RMI/ RPC, MoM, CORBA

2. RMI/RPC: Middelware zur Implementation verteilter Anwendungen. Baut auf der Semantik

von Prozeduraufrufen auf. Im Client wird der Dienst genauso aufgerufen wie eine lokale

Prozedur, lokale Funktion.

Message Oriented Middleware (MOM): ist eine Middleware, unterstützt die Implementation

von verteilten Anwendungen, geeignet bei Toleranz in Bezug auf Antwortzeiten, nomadic

computing, Austausch von nicht spezifischen Nachriten mittels Warteschlangen (Queues)

CORBA: Ein Object Request Broker (ORB) ist die Middleware Technologie, welche die

Kommunikation und den Datenaustausch zwischen Objekten ermöglicht. Objekte und deren

Funktionalität sind von der Kommunikation der Objekte völlig getrennt

3. CORBA, sprachunabhängig, bereits Erfahrung, mit JacORB auch gratis ORB für Java

12.01.2009 26 Jousi B. Marti

Aufgabe 27

UML Sequenzdiagramme


1. Was stellen Sie mit UML Sequenzdiagrammen dar?

2. Erklären Sie die Elemente, die Sie in einem Sequenzdiagramm verwenden können.

3. Zeichnen Sie ein UML Sequenzdiagramm für Ihren Message Logger Viewer. Modellieren Sie

insbesondere, wie zwei neue Einträge im Viewer dargestellt werden?

Musterlösung:

1. Zeitlicher Ablauf der Objekt Komponenten – Kommunikation.

2. Aktor, Objekt, Lebenslinie (Zeit), Meldungen (synchron, asynchron)

3. TODO

Aufgabe 28

Deployment Distribution

1. RPC/RMI/IDL: Gemeinsamkeit

2. Wieso RMI ohne IDL

3. Fehlersemantiken

4. IDL des Message Logger

Musterlösung:

1. Middleware, Client Server, Verteilte Systeme

2. Beschreibt mit Java Interfaces

3. Maybe: ignoriert Fehlerfälle

At-least-once: mindestens einmal ausgeführt

At-most-once: höchstens einmal ausgeführt

4.

12.01.2009 27 Jousi B. Marti

Aufgabe 29

Deployment Konfigurationsmanagement: Versionierung

Sie haben im Unterricht ein einfaches Versionskonzept kennen gelernt.

1. Wie ist dieses Versionskonzept aufgebaut?

2. Was ist die exakte Bedeutung der einzelnen Stellen?

3. Worin liegt der Hauptnutzen, wenn dieses Konzept konsequent eingesetzt wird? Und für

wen?

Musterlösung:

1. Drei Stellen, Major, Minor und Bugfix Maintenance.

2. Major: Signalisiert nichtkompatible Änderung

Minor: Signalisiert kompatible Erweiterung.

Maintenance Bugfix: Signalisiert ausschliesslich eine Implementationsänderung

3. Anhand der Versionsnummer kann der Entwickler sehr schnell erkennen, welchen Aufwand

es bedeutet, die neue Verison zu integrieren: Muss er ggf. Seine SW migrieren (Major), kann

er sie direkt einsetzen und evtl neue Funktionen nutzen (Minor) oder ‚sollte‘ er sie sogar

einsetzten um Fehler zu behenben (Bugfix).

Aufgabe 30

???

12.01.2009 28 Jousi B. Marti

Aufgabe 31

V-Modell

1. Wo kommt das V-Modell im Rahmen des HTAgil vor?

2. Skizzieren Sie das V-Modell auf die Wandtafel oder ein Blatt Papier und bezeichnen Sie die

wichtigen Elemente und Beziehungen

Musterlösung:

1. Es beschreibt den Ablauf einer einzelnen Iteration.

2. „Bild des V-Modells“ skizzieren können – wichtig, validieren und Verifizieren richtig

einsetzen können.

MEP SS 08 - ThomasGalliker.ch · Der Zeitplan Ihres Projektes ist recht eng. Sie stehen also unter...

Documents

Transcript of MEP SS 08 - ThomasGalliker.ch · Der Zeitplan Ihres Projektes ist recht eng. Sie stehen also unter...