Analyse-Methodik

563 Aufrufe

Veröffentlicht am

Motivation für die Verwendung von Analyse Methodik in der Softwareentwicklung, UMS, Klassendiagramme, Sequendiagramme, Statusdiagramme

Veröffentlicht in: Ingenieurwesen
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
563
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Analyse-Methodik

  1. 1. Softwareentwicklungs- Methoden – Wozu dient das denn? 31.10.2009 - Ch. Santschi
  2. 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. 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. 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. 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. 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. 7. Methodenneutrale Grundprinzipien des Softwareentwicklung Abstraktion Hierarchien Kapselung (Verhinderung von sog. Seiteneffekten) Modularisierung 31.10.2009 - Ch. Santschi
  8. 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. 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. 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. 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. 12. Strukturierte Analyse & Strukturiertes Design Entity Relationship Modeling Datenflußdiagramme und Datenwörterbuch Zustandsänderungsdiagramme 31.10.2009 - Ch. Santschi
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. Use Cases (Geschäftsvorfälle) 31.10.2009 - Ch. Santschi
  25. 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. 26. Klassendiagramme, Symbole 31.10.2009 - Ch. Santschi
  27. 27. Statische Beschreibung: Klassendiagramme, Symbole Vererbung 31.10.2009 - Ch. Santschi
  28. 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. 29. Dynamische Beschreibung: Interaktionsdiagramme, Symbole Sequenzdiagramm aFahrzeug aFahre : Fahrzeug : Fahre setFahrzeugDaten( bschleunige() Objekt Nachricht Objekt- Lebenslinie 31.10.2009 - Ch. Santschi
  30. 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. 31. Dynamische Beschreibung: ...wird ein Sequenzdiagramm hinzugefügt 31.10.2009 - Ch. Santschi
  32. 32. Dynamische Beschreibung: Sequenzdiagramme
  33. 33. Dynamische Beschreibung: Zustandsdiagramme 31.10.2009 - Ch. Santschi
  34. 34. Dynamische Beschreibung: Aktivitätsdiagramme 31.10.2009 - Ch. Santschi
  35. 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. 36. Implementierungsdiagramme - Komponentendiagramme 31.10.2009 - Ch. Santschi
  37. 37. Implementierungsdiagramme Verteilungsdiagramme 31.10.2009 - Ch. Santschi
  38. 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. 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

×