Das Dokument behandelt verschiedene Methoden der Softwareentwicklung, deren Grundlagen und Ziele sowie die Bedeutung des Software Engineerings, das systematische und methodische Unterstützung bietet. Es werden aktuelle Ansätze wie strukturierte Analyse, objektorientierte Programmierung und die Unified Modeling Language (UML) vorgestellt, die neue Möglichkeiten zur Modellierung und Darstellung von Softwaresystemen bieten. Zudem wird auf die Notwendigkeit plattformunabhängiger Lösungen hingewiesen, insbesondere in Hinblick auf Java und die Rolle der Java Virtual Machine.

1. Softwareentwicklungs-
Methoden – Wozu dient das denn?
31.10.2009 - Ch. Santschi

2. Inhalt
Überblick der SW-
Entwicklungsmethoden
Grundlagen des Software-Engineering
Aktuelle Methoden der
Softwareentwicklung
Unified Modeling Language
Ausblick: Plattformunabhängige
Lösungen mit C# und .NET
31.10.2009 - Ch. Santschi

3. Warum Softwareengineering?
Durch Leidensdruck:
Software wird immer komplexer
Die Software(weiter)entwicklung dauert
zu lang
Der erzeugte Code ist oft unzuverlässig
Die Wartung und Fortschreibung von
Softwareprodukten ist problematisch
31.10.2009 - Ch. Santschi

4. Was ist Softwareengineering?
Systematisches Vorgehen
Methodische Unterstützung
Intensiver Einsatz von Instumenten
Entwicklungsarbeit und
Projektorganisation treten stets paarweise auf
31.10.2009 - Ch. Santschi

5. Aktuelle Methoden der
Softwareentwicklung
Funktional: Strukturierte Analyse &
Strukturiertes Design (rückläufig)
Programmiersprachen: C, Pascal
Objektorientiert: Unified Modeling
Language (zunehmend)
Programmiersprachen: C++, C#, Java
31.10.2009 - Ch. Santschi

6. Ziele der methodischen
Unterstützung
 (Methodische Unterstützung rechnet sich nur bei
größeren Systemen)
 Vermeidung von frühen Fehlern
 Unterstützung bei der Anforderungsdefinition
 Unterstützung bei der Systemarchitektur
 Unterstützung bei der Programmierung
 Unterstützung bei Planungs- und Organisationsfragen
 Kommunikationsplattform zwischen
fachwissenschaftlichen Bedürfnissen und
informationstechnischen Belangen
31.10.2009 - Ch. Santschi

7. Methodenneutrale Grundprinzipien
des Softwareentwicklung
Abstraktion
Hierarchien
Kapselung (Verhinderung von sog.
Seiteneffekten)
Modularisierung
31.10.2009 - Ch. Santschi

8. Strukturierte Analyse & Strukturiertes Design
Kernelemente: Datenflußdiagramme und
Datenwörterbuch
Bestandteile der Datenflußdiagramme:
Funktionsknoten, Datenstöme, Speicher,
Terminatoren
Vorgehensweise: Funktionsknoten werden mit
einem das Ganze benennende Kontext-
Diagramm zunehmend kokretisiert
31.10.2009 - Ch. Santschi

9. Strukturierte Analyse & Strukturiertes Design
Sukzessive Konkretisierung, jeder Knoten
wird in einem neuen Datenflußdiagramm
(neue Ebene) solange verfeinert, bis eine für
die Weiterbearbeitung angemessene
Granularität erreicht ist.
Die so entstandene Vielfalt von
Funktionsknoten unterstützt Planungs- und
Organisationsfragen
Die Vorgehensweise für das
Datenwörterbuch ist analog
31.10.2009 - Ch. Santschi

10. Strukturierte Analyse &
Strukturiertes Design
Später wurde das Entity Relationship
Modeling (ERM) integriert,
eine bedeutsame Erweiterung, mit der
die ganze Datenlogik zuverlässig
definiert werden konnte
Speicher der Datenflußdiagramme der
Datenflußdiagramme gelten als
Entitätskandidaten
31.10.2009 - Ch. Santschi

11. Strukturierte Analyse & Strukturiertes Design
Zur Abbildung der Prozeßdynamik
wurden später noch Elemente der
Zustandsänderungsdiagramme der
Methode zugefügt
die Schaltlogik wurde von Schalt-
Datenströmen gesteuert, die Prozesse
(Funktionsknoten) aktivieren und
deaktivieren.
31.10.2009 - Ch. Santschi

12. Strukturierte Analyse & Strukturiertes
Design
Entity Relationship Modeling
Datenflußdiagramme und
Datenwörterbuch
Zustandsänderungsdiagramme
31.10.2009 - Ch. Santschi

13. Strukturierte Analyse &
Strukturiertes Design
Nach einem bestimmten Algorithmus
wurden die so erstellten
Datenflußdiagramme in einen
hierarchischen Systementwurf
umgewandelt, ganz oben stand die
main() Start-Funktion.
31.10.2009 - Ch. Santschi

14. Strukturierte Analyse &
Strukturiertes Design
Diese Vorgehensweise erzwang Systematik
(Top-Down), taugte auch als
Kommunikationsebene, jedoch
war die Fortschreibbarkeit unsicher,
die Übernahme und Anpassung von
Standard-Geschäftsmodellen war schwierig
das Zusammenbauen der verschiedenen
Methoden in eine überdachende wurde von
Entwickler wenig akzeptiert
31.10.2009 - Ch. Santschi

15. Umbruch der Vorgehensweisen
Mit der Entwicklung und Akzeptanz der
objektorientierten Programmiersprachen (C++, Java)
und erweiterten Zielsetzungen wurde ein Umdenken
der Entwurfsinstrumente unabdingbar.
In 1979 wurde C zu C/C++ weiterentwickelt, Mitte
der Neunziger das rein objektorientierte Java.
Diese Sprachen erweiterten die Möglichkeiten
(konstruktiven Freiheiten) der Entwickler beträchtlich.
Die Grundprinzipien Abstraktion, Hierarchien,
Kapselung, Modularisierung, blieben weiter gültig -
wenngleich in einer anderen Ausprägung.
31.10.2009 - Ch. Santschi

16. Umbruch der Vorgehensweisen
Das mächtige Element der Vererbung
repräsentiert bei der Objektorientierung
„Abstraktion“ und „Hierarchien“
die „Datenkapselung“ wurde durch Vergabe
von Klassenprivilegien (public, private, ..)
sichergestellt.
Eine Überleitung von Strukturierten
Entwürfen zu Klassendiagrammen ist unter
Zuhilfenahme von ERM-Tabellen möglich
31.10.2009 - Ch. Santschi

17. Umbruch der Vorgehensweisen
C- Beispiel: Keine Kapselung
#include <stdio.h>
struct Hello
{
char *h;
void ausgabe(void)
{
h="Hello World"; printf("%sn", h);
}
};
main(void)
{struct Hello begruessung; begruessung.ausgabe();
begruessung.h="Testausgabe";printf("%sn",
begruessung.h);
}
31.10.2009 - Ch. Santschi

18. Umbruch der Vorgehensweisen
C++-Beispiel: Kapselung erzeugt Compilerfehler
#include <stdio.h>
class Hello
{private:
char *h;
public:
void ausgabe(void)
{
h="Hello World"; printf("%sn", h);
}
};
main(void)
{class Hello begruessung; begruessung.h;}
//begruessung.ausgabe();}
31.10.2009 - Ch. Santschi

19. Unified Modeling Language
(UML)
 Eine Sprache zur Beschreibung & Modellierung
von Softwaresystemen
 Grundgedanke - einheitliche Notation
 Darstellung verschiedener Sichtweisen
 Rahmenwerk zur Darstellung von Prozessen
 Code Generierung (Code-Hülsen)
 Ab 1997 Unified Modeling Language
31.10.2009 - Ch. Santschi

20. Diagrammbeschreibung -
Diagrammtypen
Nutzungsumgebung: Use Cases
Statische Beschreibung: Klassendiagramme
Dynamische Beschreibung:
Sequenzdiagramme
Interaktionsdiagramme
Zustandsdiagramme
Aktivitätsdiagramme
Implementierung
Komponentendiagramme
Package Diagramme
31.10.2009 - Ch. Santschi

21. Statische Beschreibung: Use Cases
(Anwendungsfalldiagramme)
Geschäftsprozesse, allgemeine
Einsatzmöglichkeiten
Zusammenwirken von
Personen (Akteuren) mit einem System
Die durch Use Cases abgebildeten Tätigkeiten
sind verbal zu beschreiben
31.10.2009 - Ch. Santschi

22. Use Cases (Symbole)
<<extend>>, <<uses>> erweitert den
„Basis Use Case“, der Basis Use Case
kann auch ohne die Erweiterung
arbeiten
<<extend>> Erweiterung
(Flug buchen)
Basis Use Case
(Reise verkaufen)
31.10.2009 - Ch. Santschi

23. Use Cases (Symbole)
<<include>>Die gemeinsame
Funktionalität zweier Use Cases wird
durch einen Dritten beschreiben. Der
Dritte ist stets Bestandteil der ersten beiden
<<include>>
Wareneingang
Zukauf
Wareneingang
Produktion
„Dritter“
(Ware einlagern)
<<include>>
31.10.2009 - Ch. Santschi

24. Use Cases (Geschäftsvorfälle)
31.10.2009 - Ch. Santschi

25. Statische Beschreibung:
Klassendiagramme
 sind die wichtigsten Diagramme der UML
 dokumentieren die statische Struktur der
Klassen
 in einem System und
 ihre Beziehungen untereinander
 insbesondere
 Vererbung
 Assoziation
 Aggregation und Komposition
31.10.2009 - Ch. Santschi

26. Klassendiagramme, Symbole
31.10.2009 - Ch. Santschi

27. Statische Beschreibung: Klassendiagramme, Symbole
Vererbung
31.10.2009 - Ch. Santschi

28. Dynamische Beschreibung:
Interaktionsdiagramme
Nachrichten und Zusammenarbeit der
Objekte im zeitlichen Ablauf
Sequenzdiagramm:
Zeitliche Aufrufstruktur mit wenigen Klassen
Kollaborationsdiagramm:
Zeitliche Aufrufstruktur mit wenigen
Nachrichten
31.10.2009 - Ch. Santschi

29. Dynamische Beschreibung:
Interaktionsdiagramme, Symbole
Sequenzdiagramm aFahrzeug aFahre
: Fahrzeug : Fahre
setFahrzeugDaten(
bschleunige()
Objekt
Nachricht
Objekt-
Lebenslinie
31.10.2009 - Ch. Santschi

30. 31.10.2009 - Ch. Santschi
Dynamische Beschreibung:
Zum statischen Klassendiagramm...
Konstruktor()
person(Object) : Void
merkeBuch(Object) : VoidKonstruktor()
ausgeliehen(Object) : Void
buch(Object) : Void
PersonBuch
*
1
pname : Objectname : Object

31. Dynamische Beschreibung:
...wird ein Sequenzdiagramm
hinzugefügt
31.10.2009 - Ch. Santschi

32. Dynamische Beschreibung:
Sequenzdiagramme

33. Dynamische Beschreibung: Zustandsdiagramme
31.10.2009 - Ch. Santschi

34. Dynamische Beschreibung: Aktivitätsdiagramme
31.10.2009 - Ch. Santschi

35. Implementierungsdiagramme
 Darstellung von verteilten Anwendungen
und Komponenten
 (Übersetzungseinheiten, ausführbare
Programme, Hardwarestruktur)
 Komponentendiagramme
 Zusammenhänge der Software
 Verteilungsdiagramme
 Hardwareaufbau
31.10.2009 - Ch. Santschi

36. Implementierungsdiagramme -
Komponentendiagramme
31.10.2009 - Ch. Santschi

37. Implementierungsdiagramme Verteilungsdiagramme
31.10.2009 - Ch. Santschi

38. Was haben die einzelnen
Diagramme miteinander zu tun?
Verbale Beschreibung der Use-Case-
Diagramme liefert Objekt-, Attributs- und
Methodenkandidaten: Sequenzdiagramm
Sequenzdiagramm definiert Nachrichten
zwischen den Objekten: Klassendiagramm
(weitere Attribute und Methoden) mit
Beziehungen zwischen den Klassen
entsprechend der Nachrichten
Die Aussagen von Sequenz- und
Kollaborationsdiagramm sind äquivalent
31.10.2009 - Ch. Santschi

39. Ausblick: Plattform-
unabhängige Lösungen
Die rasche Akzeptanz des Internet erforderte
plattformunabhängige Lösungen.
Dies wird derzeit nur von Java geleistet.
Plattformunabhängigkeit ist aber keine Frage
der Programmiersprache, sondern vielmehr
eine Frage des erzeugten Zwischencodes,
etwa der class-Dateien von Java, die dann
von einer JVM (Java Virtual Maschine,
standardisiertes Bestandteil aller gängigen
Betriebssysteme) interpretiert wird.
31.10.2009 - Ch. Santschi