mep ss 08 - thomasgalliker.ch · der zeitplan ihres projektes ist recht eng. sie stehen also unter...
TRANSCRIPT
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
12.01.2009 2 Jousi B. Marti
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
12.01.2009 3 Jousi B. Marti
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
12.01.2009 4 Jousi B. Marti
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.
12.01.2009 5 Jousi B. Marti
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
12.01.2009 6 Jousi B. Marti
Aufgabe 6
Kofigurationsmanagement
Sie haben die Doku Ihres Teams zur Verfügung:
• 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)
12.01.2009 7 Jousi B. Marti
Aufgabe 7
Schnittstellen
Sie haben die Doku Ihres Teams zur Verfügung:
• 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
12.01.2009 8 Jousi B. Marti
Aufgabe 8
Reviews
Sie haben die Doku Ihres Teams zur Verfügung:
• 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
12.01.2009 9 Jousi B. Marti
Aufgabe 9
Modularisierung
Sie haben die Doku Ihres Teams zur Verfügung:
• 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
Sie haben die Doku Ihres Teams zur Verfügung:
• 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
Sie haben die Doku Ihres Teams zur Verfügung:
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.