Wirtschaftsinformatik (Bachelor-Studiengang): Software-Engineering (3. Semester)
Sie sind hier: Startseite › Wirtschaftsinformatik › Grundlagen des Software-Engineering
DW / CM, Kurs vom 01.04.2003 - 30.09.2003
Einführung / Überblick
Begriffe
Software Engineering:
Zielorientierte Bereitstellung und systematische Verwendung von- Prinzipien
- Methoden
- Konzepten
- Tools
Software:
Programme, Daten und Dokumentationen zur Unterstützung von Prozessen / Lösung von Aufgaben.
Software-System:
Besteht aus Komponenten, die untereinander in verschiedenen Beziehungen stehen.
Software-Produkt:
Software aus Anwendersicht.
System-Software:
Hardware-abhängige Basis-Software (Betriebssystem, Compiler, Datenbanken, Kommunikationsprogramme).
Anwendungs-Software:
Unterstützt ein Anwenderproblem / einen Business Process.
Anwender:
Nutzt Ergebnisse von Anwendungs-Software oder liefert Daten.
Benutzer:
Setzt Software ein und bedient sie.
Prinzipien:
Allgemeingültige, abstrakte Handlungsgrundsätze.
Methoden:
Planmäßig angewandte, begründete Vorgehensweisen zur Erreichung festgelegter Ziele. Aufteilung in konkrete Arbeitsschritte.
Verfahren:
Ausführbare Vorschriften zum gezielten Einsatz von Methoden. Beziehen sich auf einen konkreten Anwendungsbereich.
Notation:
Darstellung von Informationen durch Symbole zur Beschreibung von Konzepten.
Modelle / DB-Schema
- Klassenmodell - Datenbankschema
- Objekte - Tabellen
- Beziehungen - Relationen
Allgemeine Anforderungen:
- Persistenz
- Suche
- Navigation
- Filter
Bildbeschreibung "": Bestellung (Daten), Kunde (Name, Adresse), Artikel (Nummer, Name, Preis). Beziehung Kunde zu Bestellung und Bestellung zu Artikel 1:n.
Charakteristika von Software
- immateriell (kann man nicht "anfassen")
- leicht änderbar
- technischer Kontext ändert sich (Betriebssystem-/Datenbankversion)
- Anwendungskontext ändert sich (neue Prozesse müssen integriert/unterstützt werden)
- schwer zu "vermessen"
Conceptual Divergence
Beobachtung, dass sich in der Praxis die Business-Systeme nicht 1:1 abbilden lassen.
- Business-System notiert
- Implementierung
Hinweis: Aber: Beziehungen zum ursprünglich Prozess sind schwer zu erkennen!
Convergent Engineering
- Geschäftssicht ("Business Perspective")
- Software-Sicht ("Software Perspective")
Rollen bei der Software-Entwicklung
Entwicklung:
Erstellt Produkt im Rahmen eines Entwicklungsprozesses. Dieser ist in Phasen unterteilt.
Management:
Koordination aller Aktivitäten, Kontakt mit dem Kunden.
Qualitätssicherung:
Prüft, testet.
Wartung und Pflege:
Bugtracking (Fehlerverwaltung/-beseitigung), Anpassung an neue Anforderungen.
Phasen der Software-Entwicklung
- Analyse
Problemanalyse, Planung - Definition
Anforderungsdefinition, Prämissen für die Realisierung - Entwurf
Architektur, Komponenten, Schnittstellen - Implementierung
Codierung / Generierung - Abnahme / Einführung
Übergabe, Abnahmetest, Installation, Schulung, Inbetriebnahme - Wartung
Fehlerbeseitigung, Änderungen, Optimierung
Analyse
Ziele:
- Beschreibung der Ausgangssituation
- Definition der Ziele der Anwender
- Ressourcenplanung (personell, finanziell, zeitlich, technisch)
Aktivitäten:
- Voruntersuchung (Marktanalyse, Kundenanfragen)
- Ist-Situation erheben
- Strukturierung des Systems
- Durchführbarkeitsuntersuchungen
- Projektplan
- Wirschaftlichkeitsbetrachtung
Ergebnisse:
- Situationsstudie, Projekt-Kalkulation/-Plan
Definition
Ziele:
- Was soll das System leisten?
- Definition von Prämissen zur Realisierung
Aktivitäten:
- Anforderungen ermitteln
- Anforderungen festlegen und beschreiben
- Anforderungen validieren (Vollständigkeit, Konsistenz, technische Durchführbarkeit)
Ergebnisse:
- Objektmodell (Datenmodell, Funktionsmodell), Benutzerschnittstelle, Projektplan
Entwurf
Ziele:
- Software-technischer Entwurf
Aktivitäten:
- Analyse der Einsatzbedingungen (Umgebung)
- Entwurf der Systemarchitektur
- Definition der Systemkomponenten
- Festlegung der Schnittstellen/Abhängigkeiten
- Validierung der Architektur
Ergebnisse:
- Beschreibung der Komponenten und ihrer Struktur
Implementierung
Ziele:
- Umsetzung der Entwurfsergebnisse in ausführbarer Form
- Sicherung der Fehlerfreiheit und der Funktionalität der Implementierung
Aktivitäten:
- Verfeinerung der Algorithmen
- Codierung / Generierung
- Mapping des logischen Datenmodells auf ein physisches DB-Konzept
- Prüfung der semantischen Vollständigkeit/Korrektheit der Komponenten
- Test des Zusammenwirkens der Komponenten
- Beseitigen von Fehlern, ergänzen fehlender Funktionalität
Ergebnisse:
- Quelltexte, Testprotokolle, Datenstrukturen
Abnahme /Einführung
Ziele:
- Abnahme und Einführung beim Anwender
Aktivitäten:
- Übergabe des Produktes einschließlich der Dokumentation
- Abnahmetest
- Installation in der Zielumgebung
- Schulungen der Benutzer/Administratoren
- Inbetriebnahme
Ergebnisse:
- Übergebene Software, Dokumentation
Wartung
Ziele:
- Gewährleistung der produktiven Nutzung
- Fehlerbeseitigung
- Änderungen/Ergänzungen
Aktivitäten:
- Stabilisierung und Optimierung der Installation (Wartung)
- Anpassungen/Erweiterungen (Pflege)
Prinzipien
Prinzip der Abstraktion:
- Verallgemeinerung
- Erfassen des Wesentlichen
- Ergebnis: Modell der realen Welt
- Klassenbildend, Kompexbildend
Prinzip der Strukturierung:
- Zerlegung in wechselseitig abhängige Komponenten
- Basis für arbeitsteiliges Vorgehen
- Erhöhung der Verständlichkeit
- Verbesserung der Wartbarkeit
- Erleichterung der Einarbeitung
- Unterstü tzung von Wiederverwendung
Prinzip der Hierarchisierung:
- Spezialfall der Strukturierung
- Rangordnung, Über-/Unterordnung
- Basiert auf Baumstrukturen
- Festlegung anhand von Bedeutungen, Eigenschaften oder Zusammenhängen
Prinzip der Modularisierung:
- Aufteilung in (austauschbare) Bausteine
- Festgelegte Schnittstellen (information hiding)
- Modul ist kontextunabhängig
Vorteile:
- Höhere Änderungsfreundlichkeit
- Bessere Wartbarkeit
- Bessere Strukturierung
- Bessere Überprüfbarkeit
Prinzip der Standardisierung:
- Vereinheitlichung des Entwicklungsprozesses
- Einhalten überbetrieblicher Standards
- Einhalten betrieblicher Richtlinien
- Einhalten interner Standards
Vorteile:
- Bessere Akzeptanz am Markt
- Einheitliche Gestaltung der Dokumentation / des Codes
- Nutzbarkeit externer Komponenten
- Erleichterung der Einarbeitung und Wartung
Vorgehensmodelle
Vorgehensmodelle (auch Prozessmodelle genannt) beschreiben den organisatorischen Rahmen für eine (System-)Entwicklung.
Metapher Vorgehensmodell: Was ist wann zu tun? Was ist wann zu tun?
Vorgehensmodelle sollen zu einer disziplinierten, sichtbaren und kontrollierbaren Entwicklung führen.
Vorgehensmodelle legen u.a. fest:
- durchzuführende Aktivitäten,
- Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasen)
- Definition der Teilprodukte / Ergebnisse (Inhalt, Layout)
- Fertigstellungskriterien,
- Verantwortlichkeiten und Kompetenzen,
- Notwendige Mitarbeiterqualifikationen,
- Anzuwendende Standards, Richtlinien, Methoden und Werkzeuge.
Wasserfall-Modell
- Ältester bekannter Ansatz
- Entwicklung in sukzessiven Schritten (Aktivitäten, Phasen)
- Teilweise ist eine Rückkopplung zwischen Phasen erlaubt.
- Vielzahl von Variationen in der Anzahl und den Inhalten der Phasen.
- Weit verbreiteter Ansatz, Grundlage anderer Ansätze.
Einheitliche Notation gemäß Balzert:
- Rechtecke für Phasen, Aktivitäten.
- Ovale für Ergebnisse.
- Pfeile für Beziehungen.
- Breite der Symbole von Bedeutung.
Vorteile:
- Phasen werden in der richtigen Reihenfolge und vollständig durchlaufen.
- Am Ende einer Phase steht ein Dokument (dokumentengetrieben).
- Entwicklungsablauf ist grundsätzlich sequentiell.
- Unterstützt ein Top-Down-Vorgehen.
- Ist einfach, verständlich und benötigt wenig Management-Aufwand.
Nachteile:
- Feste, sequentielle Reihenfolge und vollständiges Durchlaufen einer Phase ist nicht immer sinnvoll.
- Dokumentation ist gegebenenfalls wichtiger als das System selbst.
- Eventuell werden Risikofaktoren zu wenig berücksichtigt.
Prototypen-Modell
Prototypen bei unklaren Anforderungen oder bei alternativen Lösungen. Prototypen zur Klärung der Anforderungen, zum experimentieren, um praktische Erfahrungen zu sammeln, als Diskussionsbasis.
Prototyping unterstützt auf systematische Weise die frühzeitige Erstellung ablauffähiger Modelle (Prototypen) des zukünftigen Systems.
Arten von Prototypen sind u.a.:
- Demonstrationsprototyp (erster Eindruck),
- Prototyp im engeren Sinne (erste Funktionalität),
- Labormuster (technische Umsetzbarkeit),
- Pilotsystem (Kern des Systems).
Zusammenhang zwischen Prototyp und Produkt:
- Prototyp zur Klärung von Problemen,
- Prototyp als Teil der Produktdefinition,
- Prototyp wird inkrementell weiterentwickelt.
Bildbeschreibung "Zusammenhang Prototyp und Produkt": Die Gesamtgrafik zeigt eine Ergänzung der traditionellen Modelle um Prototypen. Jeder Prototyp selbst muss definiert, entworfen und implementiert werden (hier nicht dargestellt). Der Teil der Aktivitäten und Produkte zeigt, dass Prototypen immer nur Ausschnitte oder Teilaspekte behandeln. PT = Prototyp.
Vorteile:
- Prototypen reduzieren das Entwicklungsrisiko.
- Prototypen können in andere Vorgehensmodelle "integriert" werden.
- Schnelle Prototypentwicklung durch entsprechende Werkzeuge möglich.
- Prototypen fördern die Kreativität.
Nachteile:
- Höherer Entwicklungsaufwand, da Prototypen zusätzlich erstellt werden.
- Gefahr der Weiterverwendung von (Wegwerf-)Prototypen.
- Grenzen von Prototypen sind oft nicht erkennbar.
- Bei Fremdentwicklung vertraglich schwer zu fassen.
Evolutionäres Modell
Versionsentwicklung:
- Ausgangspunkt sind Kernanforderungen.
- Diese führen zu einem Kernsystem (Nullversion).
- Erfahrungen mit der Version führen zu neuen, ergänzenden Anforderungen.
- Entwicklung einer neuen Version. Entwicklung ist daher Codegetrieben.
Bildbeschreibung "Evolutionäres Modell": Drei Bereiche = Grobe Beschreibung, Aktivitäten (Spezifikation, Entwurf, Implementierung) und Ergebnis (Anfangsversion, Zwischenversionen, Endversion).
Inkrementelles Modell
Variation des evolutionären Modells:
- Hier werden zunächst die Anforderungen vollständig erfasst.
- Anschließend werden wiederholt Teile der Anforderungen umgesetzt.
Bildbeschreibung "Inkrementelles Modell": Grobe Definition der Anforderungen, Zuordnung der Anforderungen zu Teilsystemen, Entwurf der Systemarchitektur, Entwicklung eines Teilsystems, Validierung des Teilsystems, Integration des Teilsystems, Validierung des Systems (wenn System unvollständig, dann zurück zu "Entwicklung des Teilsystems"), Fertiges System.
Evolutionäres/Inkrementelles Modell:
Vorteile:
- Einsatzfähige Produkte in kürzeren Zeitabständen.
- Kombinierbar mit Prototypen-Modell.
- Auswirkungen des Produkteinsatzes lassen sich untersuchen.
- Die Richtung der Entwicklung ist leichter steuerbar.
- Statt einem Ergebnis gibt es mehrere (Zwischen)-Ergebnisse.
Nachteile:
- Falls Kernanforderungen übersehen werden, muss ggf. die Systemarchitektur überarbeitet werden.
- Sind die Zwischenergebnisse an die Anforderungen ungeplanter Evolutionspfade leicht anpassbar?
Objektorientiertes Modell
Charakteristisches Merkmal der Objektorientierung ist die Wiederverwendung. Wiederverwendung, bezogen auf:
- Ebenen (Modelle, Entwürfe, Klassen)
- Gebiete (Branchen, individuell)
- Herkunft (eigen, fremd)
Hinweis: Bottom-Up-Aspekt.
Bildbeschreibung "Objektorientiertes Modell": Betrifft Anwendung, Anwendungsumgebung und Systemanbindung auf Definitions-, Entwurfs- und Implementierungsebene in den Ausprägungen eigen und gekauft.
Vorteile:
- Verbesserung von Produktivität und Qualität.
- Konzentration auf die eigenen Stärken.
- Nutzung von Halbfabrikaten.
Nachteile:
- Gebunden an objektorientierte Technik.
- Geeignete Infrastruktur muss vorhanden sein.
- Firmenkultur der Wiederverwendung muss aufgebaut werden.
Wiederverwendungsorientiertes Modell
Bildbeschreibung "Wiederverwendungsorientiertes Modell": Anforderungsdefinition, Systementwurf, Implementierung/Montage, Integration/Test, Einsatz. Während der ersten drei Phasen erfolgt Zugriff auf die Komponentenbibliothek. Je nach Analyse beispielsweise weiter in einer der beiden ersten Phasen.
Objektorientierung
Objekte- sind greifbar, sichtbar, intellektuell wahrnehmbar
- besitzen einen Status (aktuelle Werte ihrer Attribute)
- ein Verhalten (Methoden ihrer Klasse)
- eine Identität (Adresse im Speicher)
- sind Instanzen, Ausprägungen, Exemplare ihrer Klasse
- gehen miteinander Beziehungen ein
Beispiele für Klassen und Objekte:
- Objekte der realen Welt: Personen, Fahrzeuge
- Objekte einer Anwendung: Zeichenobjekte, Konten
Modellierung eines Autos:
- ein Auto kann sicherlich als Objekt verstanden werden
- es hat gewisse Eigenschaften
- es ist aus anderen Objekten zusammengesetzt
- es besitzt gewisse Methoden
- Kommunikation mit dem Objekt Auto durch Methodenaufrufe werden Botschaften genannt
Bildbeschreibung "Objektorientierung": Beispiel Objekt Auto. Ist aus anderen Objekten zusammengestzt, beispielsweise die Reifen. Eigenschaften = Marke, Farbe, Leistung, Baujahr. Methoden = Anlassen, Beschleunigen, Bremsen (Botschaften).
UML
Klassen-Diagramme
Elemente:
- Klassen (Namen, Attribute, Methoden)
- Assoziationen (Aggregation, Generalisierung, Abhängigkeit)
- Bedingungen
Zweck:
- Halten das Vokabular des Systems fest.
- Werden schrittweise (in allen Entwicklungsphasen) aufgebaut und verfeinert.
Zielsetzung:
- Konzepte des Systems festhalten.
- Zusammenarbeit (Collaboration) beschreiben.
- Datenstrukturen spezifizieren.
Beispiel: Formalisieren eines realen Problems.
Input: Problem, meist schriftlich formatiert, Gespräch mit Betroffenen
Bibliothek:
- besteht aus Büchern und Zeitschriften
- Studenten können gratis Bücher ausleihen
Output: Formales Modell,UML-Diagramm
Aggregation
Beispiel: Ein Tisch besteht aus einer Tischplatte und mehreren Tischbeinen.
Bildbeschreibung "Aggregation": Drückt eine "besteht aus" Beziehung aus (ein Tisch besteht aus einer Tischplatte und mehreren Tischbeinen). Der Tisch handelt stellvertretend für seine Einzelteile (Bsp.: Setzen der Tischhöhe). Die Einzelteile können auch ungebunden existieren (ein Tischbein ist auch ohne Tisch ein Tischbein).
Komposition
Speziallfall der Aggregation.
Bildbeschreibung "Komposition": Die Einzelteile können ungebunden nicht existieren (ein Kapitel muss in einem Dokument eingebunden sein). Ein Einzelteil kann nur einem Ganzen zugeordnet sein (ein Inhaltsverzeichnis kann nur einem Dokument zugeordnet sein).
Beispiel Bibliothek
Klassen identifizieren:
Objekte sind meist Nomen
- Physische Dinge wie Häuser, Personen, Maschinen
- Konzepte wie Flugroute, Sitzordnung
Assoziationen identifizieren:
Assoziationen sind meist Verben
- örtliche Angaben (neben, enthält, ist Teil von)
- gerichtete Tätigkeiten (treibt an, zieht)
- Kommunikation (spricht mit)
- Eigentum (hat, gehört)
- Erfüllen einer Bedingung (ist verheiratet mit, arbeitet für, verwaltet)
Attribute identifizieren:
Attribute sind meist in Adjektiven verborgen
- rotes Auto, ungültige Karte
oder Ausdrücken wie
- die Farbe des Autos, die Position des Cursors
zurück zum Beispiel Bibliothek:
Eine Bibliothek besitzt Bücher und Zeitschriften, welche an Studierende ausgeliehen werden. Der Ausleihvorgang wird auf einer Ausleihquittung festgehalten . Dort wird das Ausleihdatum notiert. Weiter enthält die Quittung den Ausleihgegenstand und der Name des Bezügers.
Bildbeschreibung "Beispiel Bibliothek": Klassen = Bibliothek, Bücher, Zeitschriften, Studierende, Ausleihquittung; Assoziationen = besitzt, ausgeliehen, festgehalten, enthält; Attribute = Ausleihdatum.
Beispiel Textverarbeitung
Das Textverarbeitungssystem erlaubt es Peter Müller und anderen Benutzern Dokumente anzulegen und zu editieren. Ein Dokument kann Text und Grafik enthalten. Text besteht aus Abschnitten, jeder Abschnitt aus Zeichen. Ein Dokument enthält außerdem verschiedene administrative Informationen wie seinen Titel, seinen Autor, den Dateinamen in dem es abgelegt wird, sowie das Datum der letzten Änderung.
Bildbeschreibung "Beispiel Textverarbeitung": Klassen = Textverarbeitungssystem, Benutzer, Dokumente, Text, Grafik, Abschnitte, Zeichen; Methoden = anlegen, editieren; Assoziationen = enthalten, besteht, enthält; Attribute = Titel, Autor, Dateiname, Datum.
