Grundlagen der Softwaretechnik

Was ist Software?

Software ist eine Reihe von Programmen, Dokumentationen und operationalen Prozeduren. Sie ist ein Satz von Anweisungen, die so angeordnet sind, dass sie vom Computer bereitgestellt und verstanden werden können.

Eigenschaften von Software

• Sie nutzt sich nicht ab
• Sie verschlechtert sich nicht
• Komplexe Wartung
• Wiederverwendung von Komponenten

Software-Kategorien

Basissoftware

Sie zeichnet sich durch die Interaktion mit der Computerhardware aus. Sie führt Funktionen aus wie Betriebssysteme, Treiber, Compiler usw.

Echtzeit-Software

Sie dient der Überwachung, Analyse und Steuerung von Ereignissen. Beispiel: Steuerung des Verkehrs, digitale Uhr usw.

Kommerzielle Software

Sie unterstützt Operationen, kommerzielle und administrative Entscheidungen. Beispiele: Gehaltsabrechnung, Warenwirtschaft usw.

Wissenschaftliche und technische Software

Die Verarbeitung ist numerisch geprägt. Sie benötigt eine hohe Robustheit der Hardware. Beispiele: Astronomie, Vulkanologie, CAD-Werkzeuge usw.

Eingebettete Software

Steuerung von Produkten und industriellen Systemen sowie Konsumgütern. Beispiele: Steuerung von Tastaturen, Mikrowellenöfen, digitale Funktionen in Automobilen usw.

Persönliche Computersoftware

Umfasst verschiedene Arten von Software für unterschiedliche Anwendungsbereiche. Beispiele: Textverarbeitung, Tabellenkalkulation, Spiele, Datenverwaltung usw.

Künstliche-Intelligenz-Software

Sie modelliert schwierige Probleme, die mit traditionellen Rechenmodellen nicht lösbar sind. Wissensbasierte Systeme, Expertensysteme, neuronale Netze, genetische Algorithmen usw. Beispiele: Spiele, Beweis von Theoremen, Robotik, maschinelles Lernen usw.

Web-Software

Systeme, die über einen Internetbrowser genutzt werden. Beispiele: persönliche Webseiten, Portale, datenbankgestützte Beratung usw.

Die Softwarekrise

Die Softwarekrise beschreibt Probleme bei der Softwareentwicklung: Software funktioniert nicht, mehrere Wartungsaufwände entstehen und die Nachfrage wächst stetig.

Probleme mit Software

• Kundenunzufriedenheit tritt häufig auf
• Software und Wartung sind schwierig
• Qualität eines Produkts, das keine Software ist, ist nicht garantiert

Zwei zentrale Ursachen

• Ein rasanter technologischer Fortschritt, der mehr als die Menschheit selbst leisten kann
• Software entwickelt sich nicht so schnell, wie neue Anforderungen gestellt werden
• Entwicklung als Handwerk
• Widerstand von Fachleuten gegen Veränderungen

Herausforderungen des Software-Engineerings

Die Interessen folgender Gruppen sind zu erfüllen: Projektbeteiligte, Benutzer, Führungskräfte und Entwickler.

• Der Prozess garantiert keine Qualität
• Termine und Kosten sind schwer abzuschätzen
• Qualität ist schwer messbar
• Qualität des Produkts ist zu garantieren
• Wartbarkeit (Möglichkeiten zur Änderung)
• Benutzbarkeit (Möglichkeiten zum Verständnis)
• Effizienz (Antwortzeit)
• Portabilität (Möglichkeiten zur Anpassung)
• Zuverlässigkeit (Fehlertoleranz)
• Funktionsumfang (Angemessenheit zum Problem)

Relevante Faktoren

• Der Fortschritt der Informationstechnologien
• Gestiegene Nachfrage der Benutzer
• Die gestiegene Nachfrage erhöht die Wettbewerbsfähigkeit und führt zu neuen Dienstleistungen.

Mythen über Software

• Ein Handbuch liefert alle Informationen für das Personal.
• Programmierer können jederzeit hinzugefügt werden, um Verzögerungen auszugleichen.
• Weitere Details können am Nachmittag ergänzt werden.
• Änderungen lassen sich leicht einarbeiten, weil Software flexibel ist.
• Wenn wir das Programm schreiben und zum Laufen bringen, ist unsere Arbeit abgeschlossen.

Software-Engineering

Software-Engineering umfasst die Festlegung und Nutzung vernünftiger ingenieurtechnischer Grundsätze, um wirtschaftlich zuverlässige Software zu erhalten, die effizient auf Maschinen arbeitet.

Es ist eine Disziplin der Informatik, die Techniken und Methoden bereitstellt, um qualitativ hochwertige Software-Werkzeuge zu entwickeln und zu warten, um Probleme zu lösen.

• Methoden – wie Software gebaut wird
• Werkzeuge – unterstützen automatisierte Methoden
• Verfahren – eine Abfolge von Schritten

Methoden, Verfahren und Werkzeuge

• Sie ermöglichen es, den gesamten Softwareentwicklungsprozess zu planen, zu überwachen und zu steuern.
• Sie bilden die Grundlage für hochwertige Software.
• Sie erfüllen die kundenspezifischen Anforderungen und Erwartungen.

Methoden

Sie definieren verschiedene Arten von Aufgaben, Kriterien zur Messung der Qualität sowie Maßnahmen zur Anforderungserhebung.

Werkzeuge

Sie können zusätzlich oder alternativ zur Softwareentwicklung auf verschiedenen Ebenen eingesetzt werden und unterstützen die Entwicklungsumgebung. Beispiel: Umgebungen oder Codegeneratoren auf Basis von Modellierung.

Verfahren

Sie beschreiben praktisch, wie die Methoden zur Ausführung der definierten Aufgaben anzuwenden sind.

Paradigmen

Diese Aktivitäten können in verschiedenen Phasen gruppiert und sequenziert werden. Paradigmen legen Meilensteine und Sequenzen fest und sind grundlegende Bausteine des Software-Engineerings.

Typen von Paradigmen

• Klassisches Modell (Wasserfall)
• Prototyping-Modell
• Spiralmodell
• Inkrementelles Modell
• RAD-Modell (Rapid Application Development)
• XP-Modell (eXtreme Programming)
• Komponentenbasiertes Modell
• Formale Methoden
• Kombination von Paradigmen

Wahl des Paradigmas

Berücksichtigen Sie:

• die Erwartungen der Kunden,
• den Typ der zu entwickelnden Anwendung,
• die einzusetzenden Methoden und Werkzeuge.

Lebenszyklus

Der Lebenszyklus umfasst die Schritte von der Definition einer Idee bis zur Fertigstellung des Produkts.

Bestandteile des Lebenszyklus

• Phasen: Die Abschnitte des Fortschritts im Projekt.
• Aktivität: Handlungen, die zur Erstellung und Lieferung des Projekts erforderlich sind.
• Teilprodukte: Greifbare Produkte, die während des Projekts entstehen.
• Meilensteine (DM): Bedeutende Ereignisse im Projekt (Entscheidungszeitpunkte).

Ziele des Lebenszyklus

• Festlegung von Kontrollpunkten
• Überwachung der Planung, des Fortschritts und des Budgets
• Abschätzungen und Risikomanagement

Klassischer Lebenszyklus

Das klassische Modell wird auch Wasserfallmodell genannt. Es wurde auf Basis des Zyklus der Bauingenieurwissenschaften entwickelt. Es ist ein sequenzieller Ansatz, bei dem jede Aktivität in einer eigenen Phase stattfindet.

Phase 1 – Systemtechnik

• Festlegung der zu erreichenden Ziele
• Analyse auf hoher Ebene – wenig Detailtiefe
• Gesamtüberblick über das System: Aufgaben, Benutzerschnittstelle, Hardware-Schnittstelle, Integration mit anderen Systemen
• Verfügbare Ressourcen: Hardware, Software, Personal, Finanzen, Zeit, Arbeitsbedingungen

Phase 2 – Anforderungsanalyse

• Ermittlung der Bedürfnisse der Benutzer
• Analyse der notwendigen Ressourcen, sowohl des Personals als auch der Werkzeuge
• Erstellung eines Gesamtentwurfs des Systems mit Aufteilung in Module

Phase 3 – Entwurf

• Verfeinerung der in der Analysephase erstellten Systemspezifikation
• Ziel ist eine detaillierte Spezifikation des Systems

Phase 4 – Codierung

Umsetzung dessen, was im Entwurf festgelegt wurde.

Testphase

• Kein System ist frei von Fehlern.
• Modelle: V-Modell, W-Modell und weitere.
• Ein Fehler, der früh behoben wird, ist deutlich günstiger.

Phase 6 – Wartung

• Nach der Auslieferung sind häufig Änderungen am Software-Produkt gemäß den Kundenwünschen erforderlich.
• Gründe: neue Funktionalitäten oder Fehlerbehebung.

Arten der Wartung

• Evolutionäre Wartung
• Adaptive Wartung

Probleme des Wasserfallmodells

• Reale Projekte folgen selten einem sequenziellen Ablauf.
• Es ist nicht immer möglich, alle Anforderungen zu Beginn explizit festzulegen.
• Der Kunde muss oft bis zum Ende aller Phasen warten, um das Produkt zu sehen.

Wasserfallmodell – Zusammenfassung

Use Cases

Ziele

Sie müssen folgende Fragen beantworten:

• Wer sind die Akteure im System?
• Was sind ihre Ziele?
• Welche Vorbedingungen gibt es?
• Welche Hauptaufgaben werden ausgeführt?
• Welche Ausnahmen sind zu berücksichtigen?

Schritte

• Identifizierung der Akteure
• Erfassung der Anwendungsfälle
• Erstellung des Diagramms
• Ausarbeitung der Beschreibung jedes Falls
• Analyse der möglichen Beziehungen zwischen den Anwendungsfällen

Identifizierung der Akteure

Ein Akteur ist eine Person oder ein Objekt, das eine bestimmte Rolle übernimmt. Definieren Sie externe Einheiten, die mit dem System interagieren: Benutzer, andere Systeme, Geräte usw.

Wie identifiziert man Akteure?

• Wer nutzt das System?
• Wer wartet das System?
• Wer nutzt das System oder wird von ihm verwendet?
• Von wem erhält das System Informationen?
• Wem stellt das System Informationen bereit?

Wie identifiziert man Use Cases?

• Welche Funktion wollen die Akteure vom System?
• Speichert das System Informationen?
• Werden Informationen erstellt, gelesen, aktualisiert oder gelöscht?
• Muss ein Akteur über Änderungen informiert werden?
• Muss das System auf externe Ereignisse reagieren?
• Muss das System über Ereignisse informieren?

Anwendungsfalldiagramm

Es beschreibt eine Außensicht des Systems. Externe Elemente (Akteure) werden von internen Elementen (Use Cases) getrennt dargestellt.

Use Cases

• Sie repräsentieren eine Aktivität des Systems aus externer Sicht.
• Sie dienen dazu, dass ein Akteur ein Ziel erreicht.
• Sie besitzen eine zusätzliche textuelle Beschreibung.

Akteur

Ein Akteur stellt ein externes Element dar, das mit dem System interagiert.

Inhalt der Beschreibung

• Name des Use Case
• Kurzbeschreibung / Ziele
• Vor- und Nachbedingungen
• Normaler Ablauf
• Alternativer Ablauf
• Akteure
• Einschränkungen
• Bemerkungen (falls vorhanden)

Normaler und alternativer Ablauf

• Normaler Ablauf: Der ideale Fall, in dem alles wie geplant verläuft.
• Alternativer Ablauf: Ausnahmen, Fehler usw.

Beziehungen

Assoziation

Zeigt an, dass ein Akteur an einem Use Case beteiligt ist, d. h. die Funktion des Use Case nutzt, eine Anforderung ausführt oder eine Leistung erhält.

Generalisierung / Spezialisierung

Wenn ein Akteur mit einem anderen Akteur stark verbunden ist, sodass eine Art Vererbung besteht, spricht man von einem primären und einem sekundären Akteur. Das Gleiche gilt für Use Cases.

Inklusion (include)

Wenn mehrere Use Cases eine gemeinsame Teilfolge von Funktionen haben, ist es vorteilhaft, diesen gemeinsamen Teil als eigenen Use Case zu modellieren, der von den ursprünglichen Use Cases eingebunden wird.

• Ein Use Case enthält einen anderen Use Case mit einem festgelegten Verhalten.
• Vermeidet, dieselbe gemeinsame Abfolge von Schritten in mehreren Use Cases zu beschreiben.
• Ein Use Case B wird von einem Use Case A eingebunden, wenn A das Verhalten von B wiederverwendet.

Erweiterung (extend)

Beschreibt ein Szenario, das nur in einer bestimmten Situation auftritt. Ein Use Case B erweitert einen Use Case A, wenn das Verhalten von A um das Verhalten von B ergänzt wird.

• Dient zur Darstellung besonderer Verhaltensweisen oder Ausnahmefälle, die die Anzahl der Use Cases erhöhen würden.