SWT

gistfile1.txt

Lösen der Folienaufgaben aus dem Teil von Professor Riebisch

1. Anforderungsanalyse
Fragen #1
1. Worin besteht die Bedeutung der frühen Phasen der Systementwicklung?
- In den frühen Phasen der Systementwicklung wird das System gestaltet. -> richtige Entscheidungen treffen.
- Je früher eine getroffene Entscheidung geändert wird, desto geringer der Aufwand
- Siehe auch Gewicht von Entscheidungen (Funktionsgraph: Asymptote).
- Anhand des Phasenmodells wird deutlich, dass Entscheidungen während der frühen Phasen
 der Entwicklung ein enormes Gewicht auf den weiteren Verlauf der Systementwicklung haben.
2. Nennen Sie Ziele und Techniken der Anforderungsanalyse!
- Ziel: Verstehen und Einigen auf Anforderungen des zu entwickelnden Softwaresystems. Zusätzlich 
 eine Beschreibung der Aufgabenstellung und eine Modellierung der Anforderungen. Dies soll den
 Anwender mit den möglichen Lösungen vertraut machen und eine Basis für Planung bereitstellen. 
- Techniken: W-Fragen, Zuhören, Prüfung der Anforderungen, Projektdokument, Spezifikation, Szenarien, Use Cases ~~~
3. Geben Sie eine Definition für Use Case und Use-Case-Diagramm an!
- Eine Menge von Aktivitäten aus der Sicht der Akteure!!! Keine technische Realisierung.
- Ein Szenario, erst die Menge von Use-Cases beschreibt das "Systemverhalten".
- Use-Case-Diagramm stellt die statische Beziehung von Aktivitäten und Akteuren dar.
- Ein Use Case stellt einen typischen Ablauf eines Systems dar.
  Dazu werden die an diesem Ablauf beteiligten Akteure und die auszuführenden Aktionen
  genannt. Diese Aktionen führen zu einem für die Akteure wahrnehmbaren Ergebnis. 
- Ein Use-Case-Diagramm stellt einen Use Case grafisch dar, indem es die Beziehungen
 zwischen den Akteuren und den jeweiligen Use Cases aufzeigt. 
4. Geben Sie die Elemente des Use-Case-Diagramms an!
- System (Rechteck mit Namen)
- Aktion (rundes Rechteck)
- Akteur (Strichmännchen, bzw. Kasten, falls Akteur ein ext. System ist - mit Namen)
- Beziehungen zwischen Aktionen (auch extends, include, dargestellt durch Pfeile)
5. Geben Sie die Gliederung für Use-Case-Beschreibungen an!
- Eine Use-Case-Beschreibung besteht aus einem Namen, abhängigen (vorher absolvierten)
  Use Cases, Vor- und Nachbedingungen, Invarianten, einer Liste von Aktionen, Akteuren, 
  Ausnahmen und Anmerkungen.
6. Wozu dient ein Paket der UML?
- Um zusammengehörige Dinge zusammenzufassen und als Abstraktionsmittel, damit
 das Gesamtmodell übersichtlicher wird.
7. Welche Elemente enthält ein Aktivitätsdiagramm?
- Start- und Endknoten (Kreis mit und ohne Mittelpunkt)
- Aktion (rundes Rechteck)
- Objektknoten (normales Rechteck)
- Objektfluss (wie Kontrollfluss nur dass zusätzllich Objekte transportiert werden)
- Verzweigung und Zusammenführung (Raute)
- Kontrollfluss (Pfeile von einem Element zum nächsten)
- Parallelisierungs- und Synchronisationspunkte (Balken)
- Swim Lanes für die Akteur-Zuordnung (Spalten wie bei einer Tabelle)
- Abbruchs-Knoten (Rechteck mit ausgeschnittenem Dreieck rechts)

1. Anforderungsanalyse
Fragen #2
8. Wozu ist Änderungsmanagement erforderlich?
- Um mit Änderungsanfragen professionell umzugehen (also sie zu koordinieren):
  Dokumentation und Protokollierung der Änderungsanfrage, um dann
  (z.B. beim nächsten Meeting) die Durchführbarkeit und den Aufwand abzuschätzen.
  Außerdem soll vor ungeplanten Änderungen geschützt werden. 
9. Nennen Sie Kriterien für die Prüfung einer Anforderungsbeschreibung!
- Eindeutigkeit, Vollständigkeit, Überprüfbarkeit, Widerspruchsfreiheit,
 Verständlichkeit, Angemessenheit, Rückverfolgbarkeit, Abstrahierbarkeit (im Sinne von Implementierungsunabhängigkeit), Klassifizierbarkeit bzgl. Bedeutung
  (vollständige Liste s. "folien_12_Anforder..." S.3)
10. Erläutern Sie die Unterscheidung zwischen Problembereichsmodell und Lösung!
- Das Problembereichsmodell kann mit dem Kunden diskutiert werden, die Lösung ist
  technisch und umfasst z.B. den technischen Entwurf und die Implementierung.
  Zusätzlich ist man bei dem Problembereichsmodell offen bei der Lösungentscheidung
  und kann uneingeschränkt nach der optimalen Lösung suchen (in Praxis aber schwer!).
- (Ein Modell ist noch keine Lösung.)
11. Warum sollte eine Anforderungsbeschreibung keine Aussagen zur technischen Realisierung enthalten?
- Weil man sich so den Spielraum für die Implementierung selbst verringert.
- Ist für den Kunden schwerer verständlich.
- Wenn die Machbarkeit einer Lösung auf einer Plattform nicht sicher ist, sollte man sich nicht
  auf die Plattform festlegen.
12. Welche Beziehungen werden im Klassendiagramm dargestellt? //siehe https://en.wikipedia.org/wiki/Class_diagram#Relationships
- Generalisierung (sub typing, sub classing)
- (Assoziation) Hat (hat Felder von anderem Typ)
- (Aggregation)  Besteht-Aus (wie Hat [ohne Existenzabhängigkeit])
- (Uses) Benutzt (referenziert, z.B. bei Methodenparametern)
13. Was ist eine Assoziation (Aggregation, Komposition)?
- Assoziation: Ein Typ benutzt einen anderen Typ (z.B. über Felder).
=> Ein Typ hat Felder vom assoziierten Typen, um Referenzen auf diesen zu speichern.
- Aggregation: Ein Typ hat Felder von anderen Typen, um Referenzen auf fremde Objekte zu speichern. Der aggregierte Typ ist semantisch ein Teil unseres Typs.
- Komposition: Ein Typ hat Felder von anderen Typen, um darin die Teile, aus denen es besteht  zu speichern.
 (Die Teile erzeugt das Objekt z.B. selbst und/oder sorgt für Existenzabhängigkeit). Die durch die Kompositon gebundenen Objekte können nicht allein existieren.

1. Anforderungsanalyse
Fragen #3
14. Was ist ein Zustandsdiagramm? (Definition)
- Ein Zustandsdiagramm zeigt alle möglichen Zustände eines Objektes als Knoten in einem Graphen
  und die Zustandsübergänge (z.B. Methoden) als Kanten.
15. Welche Elemente werden im Zustandsdiagramm der UML dargestellt?
- Startknoten (schwarzer Kreis)
- Endknoten (schwarzer Kreis mit weißem Rand)
- Zustand (rundes Rechteck)
-> kann sequentielle & parallele Unterzustände besitzen
- Zustandsübergang (Pfeil)
-> Kontrollfluss & Parallelisierungs- und Synchronisationspunkte
16. Für die Darstellung welcher Aspekte sollte ein Zustandsdiagramm verwendet werden im Unterschied zu Aktivitäts-, Sequenz- und Kommunikationsdiagramm?
- Zustandsdiagramme sollten verwendet werden, wenn der Zustand eines Objektes und die Möglichkeiten,
  den Zustand (über Methoden) zu wechseln verdeutlich werden soll. Somit bietet es einen Gesamtüberblick über den Lebenszyklus eines
  Objekts (Gesamtverhalten).
17. Wozu werden Unterzustände benötigt?
- Unterzustände werden benötigt, um komplexe Sachverhalte hierarchisch gliedern zu können, damit das Verständnis verbessert wird. 
 
2. Entwurf 
Fragen #1
1. Nennen Sie Ziele, Techniken und Ergebnis der Phase Entwurf!
- Ziele: Anforderungen in eine technische Lösung überführen, Effiziente Entwicklung, Risiken minimieren, Verständnis schaffen,
  Kernwissen des Systems konservieren
  Software-Architektur festlegen,
  Fachliche + Technische Klassen entwerfen (Feindesign).
- Techniken: Use-Case-Diagramme, Klassendiagramme, Lösungsvariantenvergleich, Prinziplösungen aus Vorrat auswählen,
  Entscheidungen dokumentieren, Prüfung und Entwicklung integrieren -> Testfälle vor Code entwickeln!
- Ergebnis: siehe Ziele Beschreibung einer technischen Loesung, Grobentwurf, Architektur (System-, Softwaremodell)
2. Nennen und erläutern Sie die drei Klassen, die nach der Jacobson-Methode beim Entwurf für jede fachliche Klasse eingeführt werden!
- Informations-Klasse: Hält die Daten, repräsentiert das fachliche Modell und ist unabhängig von jeglicher Darstellung und Interaktion
- Schnittstellen-Klasse: Kümmert sich um die Darstellung und die Manipulation über die GUI
- Verhaltens-Klasse: Kapselt die Interaktionen, die mit dieser fachlichen Klasse verknüpft sind
-> Die Erklärungen sind ein bisschen aus dem Bild auf der Folie, dem Wissen um Model-View-Controller
  und einem kurzen Gespräch mit Prof. Riebisch entstanden. Angaben ohne Gewähr.
3. Wodurch unterscheiden sich die Realisierungen von Assoziationen mit Vielfachheit 1 und Vielfachheit * ?
- Für Vielfachheit ungleich eins werden Sammlungen von dem assoziiertem Typ verwendet
  (z.B. Listen, Mengen, Dictionaries).

2. Entwurf 
Fragen #2
4. Wie wird im Sequenzdiagramm die Zeitachse dargestellt?
- Von oben nach unten.
5. Welche Möglichkeiten der hierarchischen Verfeinerung sind im Sequenzdiagramm vorgesehen?
- Kästen, die um eine Sequenz gemalt werden, können mit einen Namen versehen werden und
  dann anderswo darüber referenziert werden.
6. Welche Informationen eines Sequenzdiagramms werden in einem Klassendiagramm ebenfalls sichtbar, und wie?
- Typen und ihre Methoden.
  Seq.d.: Typen sind oben notiert, die Pfeile, die auf ihre Lebenslinie zeigen, zeigen den Methodenaufruf auf sie.
  Klassend.: Typen sind Kästen, Methoden stehen in diesen Kästen (unter dem Abschnitt für die Felder).
- Implizit sind die Assoziationen aus dem Klassendiagramm im Sequenzdiagramm daraus zu erkennen, wer an wem Methoden aufruft.
7. Stellen Sie Sequenz- und Kommunikationsdiagramm gegenüber bezüglich Darstellung von Beziehungen und Zeitachse sowie Anwendungsbereich!
- In einem Kommunikationsdiagramm werden die Schritte nummeriert, anstatt wie beim Sequenzdiagramm
  an der Lebenslinie (der vertikalen Zeitachse) entlang geschrieben werden.
- Anwendung Kommunikationsdiagramm: Sinnvoll, wenn man die Objekte als Kommunikationspartner in Gruppen einteilen kann
  und/oder sie auf der gleichen Abstraktionsebene sind
- Anwendung Sequenzdiagramm: Sinnvoll, wenn man Delegation genauer betrachtet und hervorherben will, wer wen wann benutzt.
- Das Aktivitätsdiagramm stellt das Gesamt-"verhalten" dar.
- Sequenz-, Kommunikations-, ...-Diagramme stellen nur ein Szenario dar.

2. Entwurf 
Fragen #3
8. Nennen Sie Nachteile der Vererbung als Mittel der Realisierung!
- Einige Beziehungen zwischen Fachlichen Objekten können nicht sinnvoll über
  Generalisierung dargestellt werden. (Quadrat-Rechteck, Mitarbeiter-Kunde)
  Führt zu hoher Kopplung. Unflexibel (kann zur Laufzeit nicht geändert werden).
9. Warum sollte Delegation gegenüber Vererbung bevorzugt werden?
- Weil sie flexibler ist. Sie erlaubt das Wechseln von Rollen und kann
  Mehrfach-Beziehungen gut darstellen.
10. Worin liegen die Nachteile der Benutzung von Referenzen als Parameter?
- An Stellen, an denen lose Koppelung gefordert ist, sollte auf Referenzen als Parameter in soweit verzichtet werden, um Klassen nicht zu stark zusammenzukleben.
- Das ganze "schwergewichtige" Objekt wird einer Methode übergeben. siehe Punkt darunter mit Werte statt Referenzen
- (Der Typ sollte dem entsprechen, was die Methode benötigt. [Nicht einfach: Transitiv!])
- (Auf den Punkt gebracht: Hohe Kopplung.)
11. Erläutern Sie Möglichkeiten der Entkopplung zwischen Komponenten!
- Verwendung von Werten anstatt Referenzen. D.h. hier: Rückgabe von Werten anstelle von Referenzen auf Objekte, auf die man wiederrum Methoden aufrufen kann.
- (Einführung von Interfaces, um Abhängigkeiten von Implementierungen (konkreten Klassen) zu verringern.)

3. SW-Qualitätsmanagement 
Fragen #1 
1. Nennen Sie die Untermerkmale des Qualitätsmerkmals Wartbarkeit (Effizienz, Zuverlässigkeit, Übertragbarkeit)?
- überall dabei: Konformität
- Wartbarkeit: Analysierbarkeit, Änderbarkeit, Stabilität, Testbarkeit
- Effizienz: Zeitverhalten, Verbrauchsverhalten
- Zuverlässigkeit: Reife, Fehlertoleranz, Wiederherstellbarkeit
- Übertragbarkeit: Anpassbarkeit, Installierbarkeit, Koexistenz, Austauschbarkeit
2. Worin besteht der Zusammenhang zwischen Prozess- und Produktqualität?
- Produktqualität kann erst entstehen, wenn der Prozess qualitativ ist.
(Was Proz.q. ist: Siehe Liste mit konkreten Merkmalen. Die folgenden davon fand ich anschaulich:
- Termineinhaltung 
- Budgeteinhaltung 
- Produktivität  
- Leerlaufzeiten+Paralleltätigkeiten 
- Kommunikationsaufwand 
- Einarbeitungsaufwand 
- Fehlervermeidung+Rework 
- Kundenzufriedenheit 
- Mitarbeiterzufriedenheit)
3. Erläutern Sie den Zusammenhang zwischen Fehlerverweilzeit und Fehlerbehebungskosten!
- Fehler pflanzen sich fort: Je länger der Fehler im System ist, desto schwieriger ist es, diesen zu lokalisieren. Je später ein Fehler gefunden wird, desto schwieriger ist er zu beheben.
4. Warum sind Inspektionen zusätzlich zu Tests sinnvoll?
- Weil sie andere Fehler finden.
- Weil sie mehr Fehler aufdecken. (Das hängt von der Erfahrung und Expertise der Gutachter ab.)
- Weil sie kein laufendes System benötigen.
- Weil sie auf alles anwendbar sind, nicht nur auf die Implementierung.
5. Vergleichen Sie Inspektionen und Tests bezüglich Einsatzmöglichkeiten (Phasen, Produkte) und Art von gefundenen Fehlern und Mängeln!
- Tests sind erst möglich, wenn das System "läuft", also üblicherweise während der Implementierung.
- Tests decken nur Fehler ab, für die es Testfälle gibt.
- Inspektionen sind immer möglich, sofern es etwas zu begutachten gibt.
- Inspektionen decken Fehler auf, die den Gutachtern auffallen.
- Tests finden meist Fehler der äußeren Qualität (Blackbox). Inpektionen finden auch Fehler der inneren: Lesbarkeit, Wartbarkeit, usw. (Whitebox)
6. Wieso hat der unterschiedliche Einsatzzeitpunkt von Inspektionen und Tests Einfluss auf die Produktivität?
- Fehler früher finden ist besser, denn dadurch wird die Fehlerverweilzeit verringert, was wiederrum zu einer erhöhten Produktivität führt.
  Außerdem führt eine frühzeitige Analyse zu einem geringeren Rework-Aufwand und zu einer Risikominimierung. Vorallem frühe Inspektionen
  führen zu besser informierten Entwicklern und zu lesbarerem Code.

3. SW-Qualitätsmanagement 
Fragen #2 
7. Stellen Sie die Testmethoden gegenüber!
- Blackbox-Test:
  Test des Verhaltens, öffentliche Schnittstelle testen.
  Richtige und falsche Verwendung der Methoden.
- Whitebox-Test:
  Test der Internas, nicht-öffentliche Schnittstelle testen.
  Pfad- und Zweigabdeckung der Methoden.
8. Nennen Sie Testabdeckungsmaße!
- Anweisungsabdeckung < Zweigabdeckung < Pfadabdeckung
9. Nennen Sie die Gemeinsamkeiten und Unterschiede von Black- und White-Box-Tests! 
- S.o.
10. Geben Sie ein Beispiel für die Kombination von Black- und White-Box-Tests auf verschiedenen Test-Ebenen an!
- Bei der Entwicklung eines Systems wird zum Klassentest ein White-Box-Test verwendet, um das Verhalten von Methoden dieser Klasse zu überprüfen.
  Im späteren Entwicklungsprozess wird zum Integrationstest ein Black-Box-Test verwendet, um das Zusammenspiel der verwendeten Module an der Schnittstelle zu überprüfen.  Vorallem, weil beim Integrationstest, sowieso keiner das gesamte System (Whitebox) überblickt.
11. Was sind Äquivalenzklassen?
- Wertebereiche, deren Elemente bei Verwendung als Parameter ein Verhalten bewirken,
  das im Sinne des aktuellen Tests nicht weiter unterschieden werden muss.
  Z.B. alle Werte eines Bereichs "prüfen" den selben Pfad.
12. Was sind Grenzwertanalysen bei der Aufstellung von Testfällen?
- Hierbei werden die Testfälle auf mögliche Grenzwerte analysiert und folglich getestet. Beispielweise ergeben sich Testfälle für Grenzen gültiger bzw. ungültiger Äquivalenzklassen. 
Diese Analyse wird durchgeführt, da die Fehlerwahrscheinlichkeit an den Grenzwerten höher ist und somit mehr Fehler aufgedeckt werden können. 
13. Erläutern Sie Zustands-, Entscheidungs- und Use-Case-basiertes Testen! 
- Zustandsbasiertes Testen: Testen des internen Zustands, z.B. mit Whitebox-Test
- Entscheidungsbasiertes Testen: Test mit Entscheidungstabellen.
- Use-Case-basiertes Testen: Testen eines Anwendungsfalls, z.B. Blackbox-Test (Positivtest)
14. Was sind die Besonderheiten beim Testen Objektorientierter Software?
- Kapselung von Objekten behindert das (White-Box-)Testen.
- (Abstrakte Klassen nicht allein testbar.)
- Oft sind Klassen (durch Beziehungen) nicht vollständig einzeln testbar, deshalb müssen ganze (große) Module getestet werden => Große Herausforderung.

3. SW-Qualitätsmanagement 
Fragen #3
15. Stellen Sie Inspektion und Walkthrough gegenüber!
- Walkthrough:
  Durchspielen des Codes oder eines anderen Artefakts an Beispielen, sodass in Reihenfolge einer Verwendung durchgegangen wird.
  ~~~ Ist das nicht eher: Walkthrough ist das "Durchdenken" eines Algorithmus bevor man ihn schreibt - VS Inspektion die Kontrolle des fertigen Alg.
- Inspektion: 
  Eine beliebige andere Reihenfolge für das Begutachten des Codes oder eines anderes Artefakts (z.B. von oben nach unten beim Code).
16. Nennen Sie die Quelle der Kriterien für eine Code-Inspektion (einen Code-Review)!
- Eine Checkliste von Kriterien für sauberen Code (Firmen-, Projekt- und Auftragsindividuell)
- Wissen von anderen Entwicklern (Best Practices, Dos und Donts der Programmiersprache)
- Gesunder Menschenverstand (sprechende Namen und alles was der Verständlichkeit zuträglich ist)
17. Geben Sie Kriterien für eine Code-Inspektion (einen Code-Review) bezüglich Wartbarkeit an!
- Verständlichkeit:
  sprechende Namen
  Codekonventionen (Formatier- und Benennungs-Stil und Verwendung/Frameworkkonformität)
  unkomplizierte Lösung
- Stabilität:
  Defensiver Programmierstil (Vertragsmodell, sinnvolle Fehlerbehandlung)
- Änderbarkeit:
  geringe Kopplung
  hohe Kohäsion
  Starke Kapselung => KKK ;)
18. Geben Sie Beispiele für sinnvolle Zeitpunkte für Reviews an, und erläutern Sie diese!
- vor Freigabe der Software
-> Gewährleistung der Funktionalität und entspricht die Software der Anforderung?
- sobald eine gewisse Qualität garantiert werden muss
-> vor der Vorstellung eines Prototypen bei dem Kunden
-> bevor der Autor in Urlaub geht und die Software von ihm nicht weiterentwickelt werden kann
- auf Wunsch eines Mitarbeiters
-> sofern er sich unsicher über die Qualität seines Codes ist
- nach ca. 2-4 Implementierungswochen
-> um Qualität aufrechtzuerhalten, Fehlerverweilszeit zu reduzieren, Bad Smells rechtzeitig erkennen, Kenntnisstand aller beteiligten Akteuere auf den aktuellen Stand bringen, usw.
19. Geben Sie den Ablauf einer Inspektion an!
- (muss vorher passiert sein:) Planung
- (kann vorher passiert sein:) Vorbesprechung, individuelle Vorbereitung
- (obligatorisch:) Sitzung
- Nachbereitung
- Bewertung

3. SW-Qualitätsmanagement
Fragen #4
20. Nennen Sie die Rollen der Beteiligten an einer Code-Inspektion (einem Code-Review)! 
- Team: Erstellt die Checkliste und versucht Mängel zu finden
- Autor: Derjenige, der den Code geschrieben hat. Und den Code vorstellt.
- Gutachter: Jemand, der den Code nicht geschrieben hat und ihn begutachtet.
  Das kann z.B. ein (meist 2-3)  Kollege(n) sein, dann nennt man ihn in dieser Rolle "Peer" (Gleichgestellter).
- Am besten nicht der Chef.
21. Nennen Sie die mit Reviews und Inspektionen verfolgten Ziele!
- Aufdecken von Fehlern
- Qualitätssicherung "während" der Implementierung
- Wissenstransfer (vor allem für Neulinge)
- Anerkennung für guten Code ("Bravo, saubere Lösung!")
- Bemängelung von schlechtem Code ("So geht das aber nicht..."). Aber immer gaaanz vorsichtig Kritisieren :D

4. Wartung und Reengineering
Fragen #1
1. Worin liegt die wirtschaftliche Bedeutung des Reengineering geschäftskritischer Softwaresysteme?
- Geschäftskritische Software ist für das Funktionieren des Unternehmens essentiell.
  Findet keine Instandhaltung und Anpassung der Software statt, kann das Geschäft nicht weiter existieren.
  Vorallem weil Software altert und ohne Anpassung unbenutzbar wird.
2. Welche Rolle spielen Änderungen für die Anwendbarkeit eines Softwaresystems?
- Weil sich neue Anforderungen an das Geschäft ergeben, muss die Software an diese angepasst werden.
  Können diese nicht umgesetzt werden, behindert das das Unternehmen und führt meistens zum Auftragsverlust.
3. Nennen Sie die Risiken der Ablösung eines existierenden Softwaresystems durch eine Neuentwicklung!
- Eine Neuentwicklung ist zeit- und kostenintensiv, da Anforderungen an ein neues System nicht vollständig bekannt sind.
- Die Neuentwicklung kann Fehler einführen.
- Geschäftslogik ist nicht zureichend dokumentiert sondern irgendwo in der alten Software versteckt.
4. Erläutern Sie das Staged Model der Zustände (1-5) eines Softwaresystems!
-> 1: Entwicklung
-> Auslieferung
-> 2: Evolution <-> Evolutionäre Veränderungen
-> Verlust an Wartbarkeit
-> 3: Servicing <-> Service Patches
-> Ende der Unterstützung
-> 4: Phaseout
-> Abschaltung
-> 5: Closedown
5. Erläutern Sie die Begriffe Reengineering, Reverse Engineering und Refactoring!
- Reengineering: Untersuchung und Änderung des Systems, um es in neuer Form zu implementieren. Refactoring bezeichnet qualitätsverbessernde Anpassungen auf  niedrigerem Abstraktionsniveau, die sich teilweise automatisieren  lassen. Ein Refactoring kann somit Teil eines Reengineering sein.
- Reverse Engineering: Aus der Software Teile des Entwurfs und der Anforderungen wiederherstellen.
- Refactoring:
  Änderungen an Software durchführen, ohne das sichbare Verhalten der Software zu verändern,
  mit dem Ziel, die Verständlichkeit und Wartbarkeit zu erhöhen und zukünftige Erweiterungen und Änderungen zu erleichtern.

4. Wartung und Reengineering
Fragen #2
5. Nennen Sie die Definition von Refactoring!
S.o.
6. Durch welche Maßnahmen wird beim Refactoring das Fehlerrisiko gering gehalten?
Es werden einzelne kleine Folgen von Änderungen durchgeführt, die klar abgegrenzbar und leicht verständlich sind. Nach jeder kleinen Änderung kann der Code
übersetzt und (maschinell) getestet werden.
Die Änderungen können ohne Weiteres rückgängig gemacht werden und sind durch Tests abgesichert. 
7. Warum sollten Refactoring und Erweiterungen klar getrennt werden?
Erweiterungen ziehen (teilweise) neue Tests mit sich, während dies bei Refactoring nicht der Fall ist. Oder alte Test funktionieren nicht mehr. 
=> Man weiss nicht, welche Test man "kaputt" gemacht hat und welche wegen der Änderung nicht mehr gehen.
Zudem sind Erweiterungen häufig große Änderungen, die nicht ohne Weiteres rückgängig gemacht werden können und nicht leicht verständlich sind.
8. Welche Rolle spielen Bad Smells beim Refactoring?
- Das Erkennen von Bad Smells im Code und die Bejahung der Frage, ob dieser Bad Smell jetzt wirklich entfernt werden muss, führt zu einem Refactoring mit dem Ziel, diesen Bad Smell zu entfernen. => Durch Bad Smells erkennt man ob ein Refactoring nötig ist.
9. Ordnen Sie die Bad Smells Feature Envy, Message Chain und Shotgun Surgery Qualitätsmerkmalen zu!
- Feature Envy
-> Wartbarkeit -> Verständlichkeit, Einfachheit, Änderbarkeit
- Message Chain
-> Wartbarkeit -> Verständlichkeit, Einfachheit, Erweitbarkeit, Testbarkeit
- Shotgun Surgery
-> Wartbarkeit -> Einfachheit, Erweitbarkeit, Verständlichkeit
(Die gehören alle zu The Couplers und hohe Koppelung vermindert Testbarkeit und Änderbarkeit. Die anderen sind aber auch einleuchtend.:)

________________________________________

Notizen zur Gryczan-Vorlesung / WAM-Begriffskatalog
(eine PDF ohne die etwas störenden Farben ist in der Dropbox [SWT-Ordner])

- Analyse kooperativer Arbeit kann über Szenarios, Interviews oder Workshops geschehen
- Kooperationsbilder dienen zur Erarbeitung eines Verständnisses und zur Rückkopplung übergreifender Aufgaben. Schwerpunkt liegt auf der Darstellung der Form der Zusammenarbeit. 
Ihre gute Verständlichkeit liegt in der Tatsache, dass sie ein ausgewähltes Szenario untersuchen und dieses mit intuitiven Symbolen darstellen.
Kooperationsbilder sind ein objektorientierter Ansatz, um Geschäftsprozesse und ihre Softwareunterstützung gemeinsam zu analysieren und zu gestalten. Sie haben keine Fallunterscheidungen und zeigen keine negativen Prozesse (komische Formulierung...).
- Leitbilder in der Softwareentwicklung: Objektwelten, Direkte Manipulation von Arbeitsgegenständen, Fabrik, Arbeitsplatz für eigenverantworliche Expertentätigkeit 
- Grundlage der WAM-Leitbilder: die unterstützende Sichtweise -> Menschen sollen in ihrer (Experten-) Tätigkeit unterstützt werden, wobei ihnen nicht die Handlungskontrolle abgenommen wird.
- Arbeitsplatztypen im Bürobereich: Arbeitsplatz für Fachleute (flexible Erledigung vielfältiger Aufgaben), Funktionsarbeitsplatz (für Fachleute für spezielle Tätigkeiten mit hoher Wiederholung), einfacher Sachbearbeitungsplatz (für Standardaufgaben, die von geringqualifizierten Personen erledigt werden)
- weitere Arbeitsplatzleitbilder: Gruppenarbeitsplatz, Selbstbedienungsautomat
- Entwurfsmuster Proxy: Der Zugriff auf ein Objekt soll durch ein vorgelagertes Stellvertreterobjekt erfolgen. Somit wird eine anpassungsfähigere und intelligentere Referenz auf ein Objekt als ein einfacher Zeiger erzeugt. 
- Entwurfsmuster Schablone: Hierbei wird das "Skelett" eines Algorithmus in einer Operation definiert und einzelne Schritte an Unterklassen delegiert. Die Verwendung einer Schablonenmethode ermöglicht es Unterklassen, bestimmte Schritte eines Algorithmus durch Einschubmethoden zu überschreiben, ohne seine Struktur zu verändern. 
- Entwurfsmuster Fliegengewicht: Bietet eine sinnvolle Anwendung, sofern eine hohe Anzahl an Objekten benötigt wird (hohe Speicherkosten!) und ein Großteil des Objektzustands nach außen verlagert werden kann. Dabei werden viele Gruppen von Objekten (z.B. die Buchstaben A,B und C) durch wenige Shared Objects ersetzt. Diese Shared Objects sollten immer über eine abstrakte Fabrik erzeugt werden, welche auch den Fliegengewicht Pool verwaltet. Bringt das Ding nicht nur was bei unveränderlichen Objekten? Jo, das ist die Idee bei intrinsischem und extrinsischem Zustand.
- Kooperative Arbeit: Verschiedene Personen arbeiten geplant und koordiniert zusammen, um ein gemeinsames Ergebnis zu erreichen.
- Koordination: Prozess zur Abstimmung von Arbeitsteilung bei kooperativer Arbeit. Sie kann auf wechselseitigen Konventionen bzw. festgelegten Regeln beruhen. 
- Kooperationsmodell: Modell, dass entweder explizit oder implizit die Zusammenarbeit (Kooperation) beschreibt und regelt. 
- Kooperationsmittel: Ein fachlich motivierter Gegenstand (z.B. Vorgangsmappe), der die Kooperation unterstützt. Er vergegenständlicht die Kooperation oder die dabei notwendige Koordination. 
- Kooperationsmedium: Ein fachlich motivierter Gegenstand, der zur Realisierung von Kooperation in Anwendungssystem dient (z.B. eMail).
- Implizite Kooperation: Hier wird der konkurrierende Zugriff mehrerer Benutzer auf gemeinsame Ressourcen im Benutzungsmodell ermöglicht und verdeutlicht. Kooperation oder Koordination selbst sind aber nicht vergegenständlicht. (z.B. Kooperation über gemeinsamen Datenzugriff)
- Explizite Kooperation: Hier wird im Benutzungsmodell deutlich, dass mehrere Benutzer kooperativ in einer gemeinsamen Arbeitsumgebung arbeiten. Geeignete Kooperationsmittel und -medien stehen für die Weitergabe von Materialien und die Koordination bereit. (z.B. Kooperation über eine gemeinsame Registratur) 
- Transparenz: Bedeutet bei der Kooperation, dass der Benutzer die Konkurrenzsituation mit Hilfe des Anwendungssystems erkennen kann. 
- Ein Material kann zu einem Zeitpunkt nur an genau einem Ort sein und dort bearbeitet werden. 
-> Mechanismen für konkurrienden Zugriff: Exklusiver Zugriff, Exklusiver Zugriff + Kopien, Nur Kopien
- Registratur: Zweck einer Registratur ist die Bereitstellung und konsistente Verwaltung von Materialien. Dazu führt sie eine Bestandsliste. 
- Prozessmuster: Ein gemeinsames Material zur Vergegenständlichung eines kooperativen Arbeitsprozesses. Es legt zudem die Verantwortlichkeiten von Personen oder Rollenträgern und Tätigkeiten in einem kooperativen Arbeitsprozess fest. Es besteht auch aus der Angabe der Abhängigkeiten von und zwischen Tätigkeiten, die bei der kooperativen Arbeit zu erledigen sind und den dazu notwendigen Dokumenten. 
- Laufzettel: Ein Arbeitsgegenstand, der von einem Anwender für einen speziellen Vorgang erstellt wird (wer ist wofür zuständig, welche Reihenfolge, welche Dokumente). Damit wird die Zusammenarbeit koordiniert und über den Stand der Vorgangsbearbeitung informiert.
- Zusammenfassung der Kooperationstypen: Implizit (Registratur), Explizit (Postfächer, Registratur), Explizite Kooperation und Koordination (Laufzettel)
- Entwurfsmuster Zuständigkeitskette: Soll enge Kopplung eines Anfragers mit dem Empfänger vermeiden, indem mehr als ein Objekt die Möglichkeit erhält, die Dienstleistung zu erbringen. Dazu werden die potenziellen Empfänger verkettet und die Anfrage an der Kette entlang geleitet. 
- Fachlicher Service: kapselt fachliches Wissen und kommuniziert mit dem Backend. 

3+1-Modellierung:
1/3 oberste Ebene: Kooperationsbilder
2/3 mittlere Ebene: Arbeitsplatzbilder
3/3 untere Ebene: IT-Interaktionsbilder
1/1 Glossar

Werkzeug: Gegenstände, mit denen Menschen im Rahmen einer Aufgabe Materialien verändern oder sondieren können. Sie vergegenständlichen wiederkehrende Arbeitshandlungen. Untergliederung in eine Präsentations-, Interaktions- und Funktionskomponente. 

Material: Gegenstände, die im Rahmen einer Aufgabe Teil des Arbeitsergebnisses werden. Werden durch Werkzeuge (und Automaten) bearbeitet und verkörpern fachliche Konzepte. Materialien müssen für die Bearbeitung geeignet sein. 

Aspekt: Ein Werkzeug bearbeitet ein Material unter einem Aspekt.

Automat: Arbeitsmittel, um Material zu bearbeiten. Sie erledigen lästige Routinetätigkeiten als eine Folge von Arbeitsschritten mit festem Ergebnis ohne weitere äußere Eingriffe.
- laufen, wenn sie einmal vom Benutzer oder der Arbeitsumgebung gestartet wurden, unauffällig im Hintergrund
- können auf ihren Zustand überprüft und im Rahmen eingestellt werden.
(^-kleine Automaten (decken den Standardfall ab). Gegensatz: große Automaten, die in Fabriken laufen und "den Takt angeben".)

Fachwert: Durch Klassen realisierted benutzerdefinierte Werte, die Werte im Anwendungsbereich modellieren. Sie verbergen ihre innere Repräsentation und verfügen über einen definierten Wertebereich und festgelegte Operationen. Zudem haben sie keine Identität (und somit keinen Lebenszyklus) und sind unveränderlich.

Behälter: Kann Materialien aufnehmen, verwalten, ordnen und herausgeben. Dazu führt der Behälter oft Verzeichnisse. (besitzen ein Ordnungsprinzip, können Konsistenzbedingungen wahren)
- kann gleichartige oder einen definierten Satz von unterschiedlichen Ggst. aufnehmen,
- vergegenständlichen oft Prozesse als sogenannte Vorgänge (z.B. Kreditakte) und dienen der Kooperation und Koordination.

Fachliche Services:
- zielen auf eine möglichst einfache Wiederverwendbarkeit ab. Dazu sollten folgende Kriterien erfüllt sein: 
- Der Dienst ist in sich abgeschlossen und kann eigenständig genutzt werden.
- Der Dienst hat eine veröffentlichte Schnittstelle. Für die Nutzung reicht es, die Schnittstelle zu kennen.
- Der Dienst ist in einem Verzeichnis registriert. (Registry)
- Der Dienst wird dynamisch gebunden.
- Der Dienst ist zustandslos.
- Dienste sind untereinander redundanzfrei.

Entwurfsmetapher: bildhafte, gegenständliche Vorstellung, die ein Leitbild fachlich und konstruktiv konkretisiert. Sie strukturiert die Wahrnehmung und trägt zur Begriffsbildung bei. 

Leitbild:
- eine benennbare, grundsätzliche Sichtweise, anhand derer wir einen Ausschnitt von Realität wahrnehmen, verstehen und gestalten.
- repräsentiert immer auch eine Wertvorstellung.
- (in der Softwareentwicklung:) kann konstruktiv oder analytisch verwendet werden.

Kooperationsmittel: siehe oben

Arbeitsumgebung + Arbeitsplatz: Die Arbeitsumgebung ist der Ort, wo Werkzeuge, Materialien und andere Gegenstände, die bei der Erledigung von Aufgaben griffbereit sein müssen, fachlich motiviert angeordnet sind. Dabei findet die eigentliche Arbeit am Arbeitsplatz (gegen Zugriff von außen geschützt) statt, während zur Umgebung noch die Orte gehören, die unmittelbar zugänglich sind.