Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:softwaretechnologie

**Dies ist eine alte Version des Dokuments!**

Software-Technologie

Schwerpunkte der Klausur

  • Vorgabe: Einfaches technisches System mit
    • Kundenanforderungen,
    • technischen Anforderungen,
    • ersten Analyseergebnissen und einem
    • vorläufigen Architektur-Klassendiagramm.
  • Dazu sind folgende Aufgaben zu lösen:
    • Anforderungsmängel finden
    • das Klassendiagramm vervollständigen
    • fünf weitere UML-Diagramme erstellen
    • zwei Entwurfsmuster und eine sonstige Entwurfsmaßnahme einsetzen
  • Zuletzt folgen acht Wissensfragen, die nichts mit dem Projekt zu tun haben.

Objektorientierte Systementwicklung

Anforderungen / Aufwandsermittlung

Anforderungen

  • Anwender können ihre Anforderungen im Vorfeld nicht erkennen! (V-Modell XT: Auftraggeber muss alle Anforderungen im Vorfeld formulieren; V-Modell 97 und RUP: Anforderungserfassung ist Aufgabe des Auftragnehmers)
  • Durchschnittswerte: Anforderungen ändern sich monatlich um 2%, ausgelieferte Software erfüllt lediglich 61% der Anforderungen, 67% der Kosten eines Projekts beruhen auf falschen Anforderungen
  • Anforderungen basieren auf Wünschen → Wünsche basieren auf Anwendungsfällen
  • Möglichkeiten, Anforderungen/Anwendungsfälle zu finden, siehe Tabellen S. 70 und 71 (z.B. Brainstorming, Workshop, Interview, Reviews etc.)

Anwendungsfälle

Ein Anwendungsfall ist eine **vollständige Systemfunktion aus der Sicht des Anwenders**, vom auslösenden Ereignis bis zum Vorliegen des gewünschten Ergebnisses. Dabei muss das auslösende Ereignis keine Anwenderaktion sein; es kann auch von einem anderen System oder aus der Systemumgebung stammen. Entsprechend kann das erwünschte Ergebnis eine Ausgabe an den Anwender, an ein anderes System oder an die Systemumgebung sein. Interne Ereignisse des Systems werden nicht betrachtet. Für jeden Anwendungsfall wird eine Bezeichnung aus einem Objekt und einem Verb gewählt. Dabei ist es nicht festgelegt, ob der Name aus Sicht des Anwenders oder des Systems formuliert wird; meist ist eine Mischung für die Verständlichkeit sinnvoll, z.B. "Getränk wählen", "Getränk zubereiten".
  • Spezifikation von Use Cases (ab S. 74)
    • Ablaufskript
    • Entscheidungstabelle
      • n binäre Bedingungen erfordern 2^n Regeln; dabei muss eine Regel mit jeder enthaltenen Irrelevanz doppelt gezählt werden
    • Aktivitätsdiagramm (ab S. 76)

=

Formulieren von Anforderungen
Stakeholder ist jede Person, Gruppe oder Institution, die an dem zu entwickelnden Produkt oder dessen Herstellungsprozess in irgend einer Weise – positiv oder negativ – interessiert ist. (Liste möglicher Stakeholder S. 81)
  • Volere-Template und -Klassifizierung S. 81
  • nicht-funktionale Anforderungen können die Systemarchitektur stärker beeinflussen als funktionale
  • Anforderungen an Anforderungen (S. 83)
    • vollständig
    • eindeutig definiert / abgegrenzt
    • verständlich beschrieben
    • atomar
    • identifizierbar
    • einheitlich dokumentiert
    • notwendig
    • nachprüfbar
    • rück- und vorwärtsverfolgbar
  • Verfälschung von Anforderungen
    • Bei der Wahrnehmung der Realität durch den Autor der Anforderung.
    • Bei der Formulierung der wahrgenommenen Realität durch den Autor der Anforderung.
  • Mögliche Verfälschungen (S. 85)
    • Tilgung
    • unterspezifizierte Prozessworte
    • Verallgemeinerung
    • Verzerrung
  • Template
    • [when][under what conditions] the system (shall | should | will) [be capable of | provide <whom> the ability to] <process> what how
      • Requirements Management
        • Requirements Engineering (Erfassung, Qualitätssicherung und Definition)
        • Requirements Tracing (Sicherstellen, dass im Laufe des Entwicklungsprozesses keine Anforderung verloren geht, und dass alles, was realisiert wird, auf einer Anforderung basiert)
        • Change Management (Umgang mit Anforderungsänderungen, Versionierung)
        • Requirements Documentation (Strukturierte Verwaltung aller Anforderungen mit Abhängigkeiten, Beziehungen, Versionen und Zugriffsrechten).

      Aufwandsermittlung

  • Warum Aufwandsermittlung?
    • Angebot auf Ausschreibung. Auftrag wirtschaftlich sinnvoll (Auftraggeber/freier Markt)? Reichen die Ressourcen?
  • Einflussgrößen (S. 88): z.B. Programmtyp, Qualität des Programmierers, Programmiersprache, Organisation etc.
  • Methoden
    • Analogieschätzung
    • Delphi-Methode
    • Faktorenschätzung
    • COCOMO (S. 89)
    • Function Points (S. 90)
    • Use Case Points

=

Analyse und Architektur

Aufgabe jeder Softwareentwicklung ist es, die Lücke zwischen den Anforderungen einerseits und einem von einem Prozessor ausführbaren Code andererseits zu schließen. Die objektorientierte Analyse hat dabei die Teilaufgabe, aus den Erkenntnissen der Anforderungsanalyse ein objektorientiertes System zu modellieren, das in der Lage ist, die Anforderungen zu erfüllen.
  • Wesentliche Sichten auf ein System (S. 91)
    • Funktionale Sicht – was soll das System wie tun?
    • Statische Sicht – Bestandteile und Strukturen des Systems
    • Kommunikationsstruktur – wer kommuniziert mit wem mit welchem Inhalt?
    • Kommunikationsablauf – wer kommuniziert mit wem wie in welcher Reihenfolge, um eine Aufgabe zu lösen?
    • Zustandsautomaten – wie verhält sich jedes einzelne Objekt, um seinen Beitrag zur Aufgabenlösung zu leisten?
    • (Das Zeitverhalten eines Systems - wer macht wann was wie lange / bis wann?)
    • (Der physikalische Aufbau eines Systems - welche Komponente sitzt wo?)
    • (Ablaufstrukturen - wie hängen verschiedene Teilabläufe zusammen?)
  • Verantwortlichkeitsprinzip (ein Objekt übernimmt genau eine sinnvoll definierte Aufgabe im System)
    • CRC-Karten (Class-Responsibility-Collaboration, S. 92, Beispiel S. 110)
  • Klassen finden
    • Beobachtung der realen Welt, lesen von Spezifikationen etc.
    • Textanalyse
      • Substantive → Synonyme/Attribute streichen → Verantwortlichkeit suchen
    • Historische Analyse
    • Jacobson-Verfahren
      • Objekte der realen Welt (Entity Classes)
      • Use Cases (Control Classes)
      • Schnittstellenfunktionen im Use-Case-Diagramm (Boundary Classes)
      • Swimlanes im Aktivitätsdiagramm
    • Outside-In-Analyse (S. 97, Beispiel Tastatur S. 98)
      • Boundary- und Entity-Objekte finden → unterster Layer der Architektur und Presentation Tier
      • Verantwortlichkeitsobjekte aus Aktivitätsdiagramm
      • Teilverantwortungen delegieren → nur noch eine Aufgabe je Objekt
      • Delegation "nach oben"

=

Architektur
The organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts… Parts that interact through interfaces include classes, components and subsystems. (RUP)
  • Sichten der Architektur (S. 94)
    • Design
    • Implementation
    • Process
    • Deployment
    • Use Case
  • Architekturmuster (S. 95)

=

Strukturen
  • Assoziation, Aggregation, Komposition (S. 99)
    • beidseitig, einseitig, undefiniert navigierbar
  • Generalisierung / Spezialisierung (S. 100)
    • disjoint / non-disjoint, complete / incomplete (Default: incomplete/disjoint)

Interfaces

Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung
  • Information Hiding
  • Prinzip der einfachen Schnittstellen
  • provided / required interface

=

Zustandsautomaten
  • Mealy-Automat: Aktionen im Zustandsübergang, Moore-Automat: Aktionen beim Betreten eines Zustands
  • Aktionen (z.B. Setzen/Testen eines Flags, Ein-/Ausschalten eines Relais) sind atomar, d.h. sie benötigen theoretisch keine Zeit → Zustandsübergänge benötigen keine Zeit
  • Aktivitäten (z.B. Öffnen einer Türe, komplexe Berechnung) benötigen Zeit → finden nur in Zuständen statt
  • Erweiterter Endlicher Automat: kann außer seinem Zustand weitere Daten verwalten, in Aktionen ändern und seine Transitionen davon abhängig machen (diese Möglichkeit sollte aber nur für Zählvariable und Flags genutzt werden)
  • History (S. 120)
  • Entwicklung eines Zustandsautomaten (S. 120)
    • Suche alle Nachrichten, die dem Objekt gesendet werden können (am einfachsten in Sequenzdiagrammen), und alle zeitgesteurten Ereignisse.
    • Suche alle External Inputs, die das Objekt empfangen kann. External Inputs sind Ereignisse, die keine Nachrichten sind, z.B. Eingangsgrößen eines Sensors.
    • Suche alle unterscheidbaren Zustände des Objekts. Ein Zustand ist eine Situation, in der das Objekt in Ruhe ist oder eine Aktivität ausübt und dabei auf etwas wartet.
    • Überprüfe gleich erscheinende Zustände darauf, ob sie wirklich gleich sind; sie sind es nicht, wenn sie auf neue Ereignisse unterschiedlich reagieren. Häufig zeigt sich dabei, dass eine zusätzliche Nachricht erforderlich ist, um einen Zustandsübergang auszulösen.
    • Prüfe, ob sich mehrere Zustände nur durch den Wert einer Zählvariablen oder eines Flags unterscheiden; denn könnte ein Erweiterter Endlicher Automat sinnvoll sein.
    • Zeichne den ersten Zustands-Übergangs-Graphen.
    • Prüfe, ob ein Event in mehreren Zuständen einen Übergang in denselben Zielzustand bewirkt; dann könnte ein Composite State sinnvoll sein.
    • Ergänze die Aktionen. Prüfe bei jeder Aktion, ob sie den Richtlinien für entry- oder exit-Aktionen genügt, sonst ordne sie auf der Transition an.
    • Überprüfe Transitionen, die in den alten Zustand zurückführen, daraufhin, ob sie die entry- und exit-Aktionen durchlaufen sollen oder nicht.
    • Definiere den Startzustand und ergänze den Initial Pseudostate und evtl. erforderliche Aktionen zur Initialisierung.
  • SDL
  • State-Event-Matrix
    • Alle geplanten State-Event-Kombinationen eintragen. Dann Leerfelder füllen:
    • Die Kombination kann auftreten und wurde einfach vergessen. Sie wird nachgetragen.
    • Die Kombination kann auftreten, das Event kann aber nicht verarbeitet werden und muss aufbewahrt werden – Eintrag "defer".
    • Die Kombination kann auftreten, soll aber ignoriert werden; Feld wird mit "–" markiert.
    • Die Kombination kann in fehlerfreiem Betrieb nicht auftreten, ist also ein Hinweis auf einen Fehler; Feld wird zunächst mit "e" markiert.
  • Behavior State Machine (steuert das Verhalten eines Objekts)
  • Protocol State Machine (unterscheidet zulässige von unzulässigen Nachrichtensequenzen, mögliche Spezifizierung von Constraints)

Constraints

A constraint is a condition or restriction expressed in natural language text or in a machine readable language for the purpose of declaring some of the semantics of an element.
  • Preconditions
  • Postconditions
  • Invarianten
  • Object Constraint Language (Beispiel S. 126)
  • Programming by Contract
    • Auftragnehmer prüft Vorbedingungen, Nachbedingungen und Invarianten

=

Design

  • Aufgaben der Designphase → Wie wird die Aufgabe gelöst? <> Analyse: Was wird gelöst?
    • Modularisierung
    • Strukturierung
    • Spezifizierung als Grundlage für Codierung und Test
  • Vier-Komponenten-Modell
    • Human Interaction Component (→ Presentation Tier)
    • Problem Domain Component (Ergebnis der Analyse, → Business Logic Tier)
    • System Interaction Component (→ Distribution Tier)
    • Data Management Component (→ Persistence Tier)
  • Ziel: Wiederverwendbarkeit und Flexibilität
    • Hat "meine Klasse" mehr Kenntnisse über das System, in dem sie eingesetzt wird, als unbedingt erforderlich?
    • Besitzt das System mehr Kenntnisse über meine Klasse, um sie ansprechen zu können, als für den eigentlichen Zweck unbedingt erforderlich?
    • Ist meine Klasse sehr hoch spezialisiert?
    • Enthält meine Klasse mehrere änderungsanfällige Aspekte?
    • Enthalten die Methoden Fallunterscheidungen?

Designrichtlinien und -empfehlungen

  • Trennung von Schnittstelle und Implementierung
  • Komposition anstatt Vererbung
  • Einrichten nicht konkreter Klassen (Kapselung von Algorithmen)
  • Wiederverwendbare Klassen erzeugen
  • Wiederverwendbare Komponenten nutzen
  • Protokolle definieren, Protokollklassen einrichten
  • Root-Klassen definieren
  • Objektbeziehungen konkretisieren
  • Performance verbessern
  • Schnittstellen zu DMC und HIC vorbereiten
  • Gerätetreiber definieren
  • Virtuelle Maschinen konstruieren

Objektorientierte Metriken (S. 147)

  • Kopplung: Wissen der Objekte über ihre Umgebung
  • Kohäsion: Verantwortlichkeit der Objekte
  • Weighted methods per class (WMC)
  • Depth in inheritance tree (DIT)
  • Number of immediate children (NOC)
  • Coupling between objects (CBO)
  • Response for a class (RFC)
  • Lack of cohesion in methods (LCOM)
  • Weitere
    • Number of message sends (NOM)
    • Number of Instance Methods (NIM, = WMC mit Einheitsgewicht 1)
    • Number of Methods Added (NMA)
    • Number of Methods Overridden (NMO)
    • Number of Operators Overloaded
    • Number of Parametrized Classes
    • Number of Objects Composed

Human Interaction Component (S. 149)

  • Benutzer klassifizieren
    • Erfahrungsstand
    • Hierarchieebene
    • Gruppenzugehörigkeit
  • Szenarios erstellen
  • Kommandostruktur entwerfen
    • Beispiele und Richtlinien studieren
    • Entwurf erstellen und überprüfen
    • Views entwerfen
    • Prototyping
    • Klassenmodell erstellen
    • Verbindung zur PDC

Data Management Component

  • Kapselung der Speicherorganisation
  • Zugriffsverriegelung und Datenkonsistenz
  • Klassenmodell der DMC → Object Server

Systemschnittstelle

Implementierung

Tests / Wartung

Prozessmodelle

Qualitätssicherung

ToDo

Übungen

Seite 12

Seite 55

Seite 63

Seite 68

Seite 86

  • Welche Techniken zur Spezifikation von Use Cases kennen Sie?
    • Aktivitätsdiagramm, Entscheidungstabelle, Ablaufskript
  • Wann ist eine Anforderung rechtlich irrelevant?
    • Wenn ihre Umsetzung im Produkt nicht zweifelsfrei nachgewiesen werden kann.
  • Welche Einflüsse könnten welche Stakeholder auf den Getränkeautomaten haben?
  • "Das Bezahlen kann durch Druck auf die Rückgabetaste abgebrochen werden; der Kunde erhält daraufhin sein eingeworfenes Geld zurück." Welche Fehler hat diese Anforderung? Formulieren Sie sie neu (dabei können es mehrere werden)!
    • Tilgung (Wann kann abgebrochen werden?), Verzerrung (Bekommt er tatsächlich sein Geld zurück?)

Seite 90

  • Für ein neuartiges Embedded System wurden 200 RFP gezählt. Es soll in C implementiert werden. Mit welchem Entwicklungsaufwand ist zu rechnen, und wie lange dauert die Entwicklung?
  • Was ergibt sich mit derselben Anzahl von RFP für eine einfache Datenbankapplikation in SQL?
  • Welcher Ihnen aus XP bekannte Begriff taucht oben in der Delphi-Methode auf?
    • System Metaphor (grundsätzlicher Überblick, grobes Verständnis des zu entwickelnden Produktes)

Seite 107

  • Was bedeutet MVC?
    • Model View Controller, ein Architekturmuster, das auf drei Schichten basiert
  • Welche Elementarmethode des V-Modells '97 hat mit Verantwortlichkeit zu tun?
    • CRC-Karten
  • Welche Objekte liefert eine Textanalyse des Satzes "Bei jedem Münzeinwurf wird der Wert der Münze vom Münzprüfer erkannt.", und warum?
    • Münze, Münzprüfer (Wert ist lediglich ein Attribut von Münze, Münzeinwurf ist eine Tätigkeit)
  • Was ist der Unterschied zwischen Assoziation, Aggregation und Komposition?
    • Aggregation → Teil-/Ganzes-Beziehung. Komposition → Aggregation mit Existenzabhängigkeit zwischen Teil und Ganzem.
  • Was stellt das nebenstehende Bild dar, und was fehlt hier eigentlich?
    • Generalization Sets
  • Die UML kennt zur Strukturierung von Modellelementen auch noch das Package. Warum ist es zur Architekturmodellierung nicht geeignet?
    • Packages definieren eher logische Einheiten auf Sourcecode-Ebene.
  • Was ist ein Persistence Tier?
    • Die Schicht der Architektur, die die Datenhaltung übernimmt.
  • Was kann ein Node enthalten?
    • Weitere Nodes und Artefakte.
  • Welche Arten von Interfaces unterscheidet die UML 2?
    • provided und required

Seite 124

  • Was ist ein Combined Fragment?
    • Mögliche Strukturierungselemente eines Aktvitätsdiagramms (z.B. opt, loop etc.)
  • Was ist eine Execution Specification?
    • Früher: Focus of Control. Veranschaulicht synchrone Aufrufe im Sequenzdiagramm.
  • Was bedeutet no-wait?
    • Das Standardverhalten in der UML 2: Asynchrone, nicht-blockierende Nachrichten
  • Warum wurde das Kollaborationsdiagramm der UML 1 in Kommunikationsdiagramm umbenannt?
  • Was ist in Abb. 5-83 fehlerhaft?
  • Was ist eine interne Transition?
    • Eine Transition in denselben State ohne entry- und exit-Aktionen auszuführen
  • Was bewirkt ein defer?
    • Eine Nachricht kann im aktuellen Zustand nicht verarbeitet werden und wird "aufbewahrt", bis ein Zustand sie behandelt, oder sie gelöscht wird.
  • Welchen Vorteil bringt die Verwendung einer State-Event-Matrix?
    • Mögliche Fehler werden gefunden, mögliche Kombinationen werden durchgespielt, unzulässige Nachrichten können identifiziert und behandelt werden

Seite 126

  • Wer ist schuld, wenn eine Precondition nicht erfüllt ist?
    • Der Auftraggeber.
  • Wer ist schuld, wenn eine Postcondition nicht erfüllt ist?
    • Der Auftragnehmer.

Seite 148

  • Wo lässt sich im Getränkeautomaten sinnvoll das Interpretermuster einsetzen?
    • Interpretieren von Schlüsseln für Getränke oder Rezepte.
  • Erstellen Sie ein Klassendiagramm des Entwurfsmusters "Zustand" für den Kassierer nach Abb. 5-86.
  • Erstellen Sie ein Sequenzdiagramm für die Systemgenerierung nach dem Klassenmodell aus Abb. 5-61. Ergänzen Sie evtl. erforderliche Set-Methoden.
  • Ermitteln Sie CBO und RFC für die Klassen Auftragsannahme, Kassierer und Zubereiter aus Abb. 5-60 und Abb. 5-61.

Seite 153

  • Nehmen Sie an, MS Word hat in einem großen Dokument mit automatischer Silbentrennung ein Wort falsch getrennt, und Sie wollen das in Ordnung bringen. Schreiben Sie dazu ein Szenario und versuchen Sie, dieses durchzuführen.
  • Erweitern Sie das Beobachtermuster (Abb. 5-102) zu einem MVC-Muster.
  • Überarbeiten Sie das Klassenmodell aus Abb. 5-61 so, dass die Grundsätze der MVC-Architektur eingehalten werden.

Seite 164

Seite 174

Seite 189

se/softwaretechnologie.1202737517.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)