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
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
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
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
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
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
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
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