Inhaltsverzeichnis

Software-Technologie

Schwerpunkte der Klausur

Tipps

Einführung

Definitionen

Software Engineering befasst sich mit Techniken und Methoden

Software Engineering ist die zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen. (Prof. Helmut Balzert)

Software Engineering ist Programmierung unter mindestens einer der folgenden beiden Bedingungen (Parnas):

Auf Software Engineering kann verzichten, wer alleine ein Programm für der einmaligen alleinigen Gebrauch entwickelt!

Objektorientierte Systementwicklung

Anforderungen / Aufwandsermittlung

Anforderungen

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
      • Implizite Annahmen
      • Unvollständig spezifizierte Prozesswörter
      • Unvollständige Komparative und Superlative
      • Modaloperatoren der Möglichkeit
      • Modaloperatoren der Notwendigkeit
    • Verallgemeinerung (Generalisierung)
      • Universalquantoren
      • Unvollständig spezifizierte Bedingungen
      • Substantive ohne Bezugsindex
    • Verzerrung
      • Nominalisierung
  • 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

Interfaces

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

=

Zustandsautomaten

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

Designrichtlinien und -empfehlungen

Objektorientierte Metriken (S. 147)

Human Interaction Component (S. 149)

Data Management Component

Systemschnittstelle

ƒ * wie sie heißt,

Die UML unterscheidet aktive und nicht aktive Objekte: Ein aktives Objekt besitzt einen eigenen Thread of Control, ein nicht aktives Objekt liegt im Thread eines aktiven und kann von ihm aufgerufen werden. In einem objektorientierten System ist also ein aktives Objekt der Kern einer Task.
  • Aktives Objekt und no-wait-Semantik
  • Timer-Service
    • Scheduler einrichten
      • preemptives Scheduling
      • nicht-preemptives/kooperatives Scheduling
        • gut durch Zustandsautomaten umsetzbar (S. 157)
      • Scheduling sollte durch Narichtenpriorität gesteuert werden

    Hardware-Schnittstelle

  • Interrupts
  • Polling
  • Ausgabe

=

Implementierung

"Run to Completion" (RTC) ist das in der UML 2 definierte Verhalten eines nebenläufigen Zustandsautomaten: Ein Zustandsautomat befindet sich vom Start bis zum Ende einer Transition im "Run to Completion Step"; dieser darf durch eine neue Anforderung an dasselbe Objekt nicht unterbrochen werden, da der Zustand des Objekts während einer Transition undefiniert ist. Zum Run to Completion Step gehören auch Methoden nicht aktiver Objekte, die von der Transition aufgerufen werden.

> SDL ist eine formale Sprache mit dem Ziel der Spezifikation und Beschreibung des Verhaltens von Telekommunikationssystemen (insbesondere in den Funktionsbereichen Anrufbearbeitung, Wartung, Fehlerbehandlung, Systemkontrolle sowie beim Entwurf von Datenkommunikationsprotokollen). Aufgrund ihrer Eigenschaften ist SDL generell zur Verhaltensspezifikation von Echtzeitsystemen geeignet. Die Sprache ist in grafischer und textueller Notation definiert. SDL enthält eine Reihe von Konzepten wie Typen-, Instanzen-, Kommunikations- und Sichtbarkeitskonzept und dynamische Semantik. Aufgrund ihrer formal korrekten Syntax und Semantik sind SDL-Spezifikationen zur automatischen Konsistenzprüfung geeignet.

Tests

Wartung

Entwicklungsprozess

Ein Prozess(modell) besteht aus

Wasserfallmodelle

Prototyping und iterative Modelle

Inkrementelle Entwicklung

V-Modell 97

V-Modell XT

Rational Unified Process

Agile Prozesse

Qualität des Entwicklungsprozesses

Qualitätssicherung

Total Quality Management (TQM) bezeichnet die durchgängige, fortwährende und alle Bereiche einer Organisation (Unternehmen, Institution, etc.) erfassende aufzeichnende, sichtende, organisierende und kontrollierende Tätigkeit, die dazu dient, Qualität als Systemziel einzuführen und dauerhaft zu garantieren. (S. 68)

ToDo

Erledigt

Übungen

Seite 12

Sie rechnen?

Seite 55

HW noch SW enthält und keine Anforderungsfestlegung benötigt?

Seite 63

 Bootstrap wurde für eruropäische Firmen quasi als Konkurrenzprodukt zu CMM entwickelt, ist aber inzwischen von SPICE abgelöst.

* Worin besteht die Verwandtschaft zwischen CMMI, SPICE und Bootstrap und der Unterschied zu CMM?

Seite 68

Seite 86

Seite 90

Seite 107

Seite 124

Seite 126

Seite 148

Seite 153

Seite 164

Seite 174

von welchen Einstellungen die Qualität abhängt.

Seite 189