Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Feb-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering.

Ähnliche Präsentationen


Präsentation zum Thema: "W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Feb-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering."—  Präsentation transkript:

1 W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Feb-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering

2 Inhalte der Vorlesung W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Feb-14Seite 2 von 23 Ziele und Kontext von Ausbreitungsrechnungen Ausbreitungsphänomene, Modellierung physikalischer Prozesse Freisetzung, Zerfall Topographie, Geländemodelle, Koordinatensysteme Windfeldmodelle Transportmodelle Dosisberechnung, chemische Prozesse in der Atmosphäre Simulationssysteme Softwareparadigmen / Frameworks Werkzeuge zur Modellierung (UML) Architektur von ABR_V2.0 Modelle in der ABR_V2.0 Benchmarks / Validierung

3 Simulationssysteme Ausgangslage: –Reihe von physikalischen Prozessen »Makroskopischen Ebene Freisetzung Transport Ablagerung »Detailebene Radioaktiver Zerfall Chemische Reaktionen Washout, rainout Turbulenz Bodeneinfluss –Unterschiedliche mathematische Beschreibungen der Prozesse Ziel: Erstellung eines Simulationssystems zur Beschreibung der radiologischen Lage Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 3 von xx

4 Simulationssysteme Rahmenbedingungen: –Einbindung in eine bestehende Infrastruktur »Systemumgebung Rechner Betriebssystem Netzwerk »Organisation Wer darf wann was W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 4 von xx

5 Simulationssysteme Definition –Ein Simulationsmodell (-system) ist ein spezielles Modell, dessen Gegenstand, Inhalt und Darstellung für Zwecke der Simulation konstruiert wird –Dabei werden nur diejenigen Merkmale des Systems modelliert, die für eine konkret zu lösende Fragestellung von Bedeutung sind. –Andere Merkmale hingegen, die für die Fragestellung von minderer Bedeutung sind, werden dabei vernachlässigt. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 5 von xx

6 Simulationssysteme Charakteristika –Dienen einem Zweck => Kontext –Sind nur in definierten Grenzen einsetzbar –Sind hoch komplex –Gesamtsystem mehr als Summe von Teilen –Systembeiträge aus verschiedenen Bereichen »Erstellung interdisziplinär »multi physics –Systemerscheinung benutzerangepasst »verschiedene Sichten nötig W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 6 von xx

7 Simulationssysteme Herausforderung –Beherrschung der Komplexität –Einhaltung zeitlicher und finanzieller Randbedingungen Lösungsansatz –Methoden des Software Engineerings »Modellierung »Prozesssteuerung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 7 von xx

8 Simulationssysteme Software Engineering –zielt auf die ingenieurmäßige Entwicklung, Wartung, Anpassung und Weiterentwicklung großer Softwaresysteme unter Verwendung bewährter, systematischer Vorgehensweisen, Prinzipien, Methoden und Werkzeuge. –"Systematisch" heißt, dass grundlegende Ingenieurprinzipien zur Beherrschung von Komplexität eingesetzt werden. –"Bewährt" heißt, dass Erfahrungen über die Wirksamkeit, Stärken und Schwächen der verwendeten Ansätze auf Basis zielgerichteter empirischer Studien als systematisch aufbereitete, nachvollziehbare Erfahrungen vorliegen. –Die Vorgehensweisen sind denen aus den klassischen Ingenieurwissenschaften wie dem Maschinenbau, der Elektrotechnik oder dem Bauwesen ähnlich. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 8 von xx

9 Simulationssysteme Ansätze zur Beherrschung der Komplexität 3 S –Simplifizierung »durch Strukturierung und Weglassen unnötiger Teile –Spezialisierung »auf räumlich und zeitlich begrenzte Teilaufgaben –Standardisierung »der Schnittstellen für die Integration und Feststellung der Verantwortlichkeit und Qualität Basis ist die Technik der inhaltlichen und zeitlichen Strukturierung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 9 von xx

10 Simulationssysteme Strukturierung mit den Elementen –Strukturierung der Systeme »Ganzes und Teile »Allgemeines und spezielles –Diversifikation der Funktionalitäten »fachlich + zeitlich –Verbergen von Details hinter Schnittstellen Standardisierung durch –Formalisierung der Beschreibungen - Produktmodelle –Formalisierung der Funktionen - Dienste und Komponenten –Wiederverwendung und Weiterentwicklung bewährter Komponenten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 10 von xx

11 Simulationssysteme Qualitätssicherung –Projektmanagement, Prozessüberwachung, Produktüberprüfung –erfordern einen Arbeitsstil, der durch die 3 K geprägt wird: Kooperation, Kommunikation und Koordination W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 11 von xx

12 Simulationssysteme Spezialisierung erfordert Standardisierung –Standardisierung der Schnittstellen ermöglicht Integration –Standardisierung der Prozesse ermöglicht Qualität –Standardisierung der Abläufe ermöglicht Effizienz –Standardisierung ist eine weitere Voraussetzung für die Konzentration auf: »Kooperation »Kommunikation und »Koordination W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 12 von xx

13 Simulationssysteme Qualitätssicherung als Basis des kooperativen Arbeitens –Qualität kann man nicht in ein Produkt hineinprüfen; sie muss hineinkonzipiert, - konstruiert und - produziert werden –Die Qualität der Produkte eines Unternehmens bestimmt dessen Image –Am Qualitätsgeschehen sind alle Abteilungen beteiligt –Systematische Qualitätsplanung ist die Voraussetzung einer erfolgreichen und wirtschaftlichen Verwirklichung der Qualitätsziele –Guter Informationsfluss zwischen allen Beteiligten verhütet Fehlentscheidungen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 13 von xx

14 Simulationssysteme Qualitätssicherung –Produktprüfung ist gut, –Prozessüberwachung besser, –beherrschte Fertigung am besten. –Richtig verstandene Selbstprüfung am Arbeitsplatz vermeidet Ausschuss und Fehlerfolgekosten. DIN ISO 9000 –Qualitätsmanagement- und Qualitätssicherungsnormen, Leitfaden zur Auswahl und Anwendung –Betont: Prozessqualität und Kundenzufriedenheit Qualitätssicherungssystem und seine Funktionsfähigkeit müssen im Rahmen eines Audits überprüft werden W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 14 von xx

15 Simulationssysteme Prozessqualität und Produktqualität nach ISO 9000 –Grundannahmen »Qualitätsziele werden während der Konzeptfindung vorgegeben. »Der Entwicklungsprozess trägt wesentlich zur Qualität des Produktes bei. »Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden. »Die Fehlerbehebung ist teuer und immer nur letzter Ausweg W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 15 von xx Merkmale und Eigenschaften des Produktes Qualität des Produktes Nachweis durch Prüfung Anforderungen und/oder Erwartungen an das Produkt PROZESS AnweisungenAusführung Prozessqualität

16 Simulationssysteme Software-Lebenszyklus –1. Problemanalyse Pflichtenheft –2. Programmentwurf Spezifikation –3. Programmierung Programm –4. Integration System –5.Testen Testbericht –6. Abnahme Abnahmebericht –7. Wartung –Ergebnis jeder Aufgabe ist ein Produkt Der Software Lebenszyklus entspricht einer zeitlichen Zerlegung der Aufgaben beim Software Engineering Klassisches Vorgehen im Software Engineering W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 16 von xx

17 Simulationssysteme W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 17 von xx Anforderungs- definition System- und Softwareentwurf Implementierung und Komponententest Integrations- und Systemtests Wartung Nach Royce (1970) Software-Lebenszyklus: Wasserfallmodell

18 Simulationssysteme Funktionale Zerlegung – Modularisierung –Wie finden man Module ? »Sprachliche modulare Einheiten »Module müssen zu syntaktischen Einheiten der Sprache passen. »Minimum an Schnittstellen »Module sollten möglichst wenig untereinander kommunizieren. »Schwache Kopplung »Bei der Kommunikation sollte so wenig Information wie möglich ausgetauscht werden W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 18 von xx

19 Simulationssysteme Funktionale Zerlegung – Modularisierung –Was charakterisiert Module ? »Explizit erkennbare Schnittstelle »Geheimnisprinzip (Information Hiding) »Abgeschlossenheit »Handhabbarkeit »Isolierte Prüfbarkeit »Integrierbarkeit »Planbarkeit »Lokalität der Entwurfsentscheidung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 19 von xx

20 Simulationssysteme Funktionale Zerlegung –Ansätze zum Auffinden von Modulen »Bottom-up Vorgehensweise Suche nach atomaren Teilen aus denen das System zusammengesetzt wird Schrittweise Abstraktion und Kombination bekannter Einzelelemente zu größeren Einheiten »Top-down Vorgehensweise Ausgehend vom Ganzen erfolgt die Zerlegung »Zerlegung in Teilsysteme und Konkretisierung in jedem Entwicklungsschritt »Jo-JoVorgehensweise Pragmatische Verbindung von Top-Down-und Bottom-up- Methode W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 20 von xx

21 Simulationssysteme Funktionale Zerlegung – Bottum-up –Vorteile: »Konkreter Ausgangspunkt garantiert solide Basis für die Softwareentwicklung »Suche nach vorhandenen Teillösungen wird begünstigt »Gut geeignet für das Testen –Nachteile: »Schwierigkeiten, Anwendungsbereich als Ziel tatsächlich zu erreichen »Notwendigkeit einer breiten Basis auf unteren Ebenen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 21 von xx

22 Simulationssysteme Funktionale Zerlegung – Top-down –Vorteile: »Anwendungsbereich steht im Mittelpunkt der Softwareentwicklung »Vollständige, exakte Spezifikationen führen genau zum gewünschten System »Die Gesamtübersicht erleichtert die Bildung geeigneter Abstraktionsebenen und führt zu einer guten Systemstruktur –Nachteile: »Gute Fähigkeiten zum abstrakten Denken erforderlich »Realisierungsprobleme werden erst spät erkannt »Ungeeignet für das Testen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 22 von xx

23 Simulationssysteme Funktionale Zerlegung – Jo-Jo –Vorteile: »Flexible Anpassung der Vorgehensweise an die sich ergebende Situationen »Reduzierte Anforderungen an das Abstraktionsvermögen –Nachteile: »Willkürliche Entscheidung, wann Wechsel der Bearbeitungsrichtung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 23 von xx

24 Grenzen der klassischen Vorgehensweide –Zeitlicher Ablauf zu starr »Festgelegte Abfolge der Tätigkeiten »Kaum iterative Verbesserungen möglich »Hoher Änderungsaufwand Neuer Ansatz –Komponentenbasierte Systeme W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 24 von xx

25 Komponente –Definition: »Eine Software-Komponente ist ein Software-Element, das konform zu einem Komponentenmodell ist und gemäß einem Composition Standard ohne Änderungen mit anderen Komponenten verknüpft und ausgeführt werden kann. –Sie zeichnet sich also dadurch aus, dass sie ein Element einer komponentenbasierten Anwendung darstellt und definierte Schnittstellen zur Verbindung mit anderen Komponenten besitzt. Die genaue Form einer Komponente ist abhängig vom jeweiligen Komponentenmodell. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 25 von xx

26 Komponente –Das Interface der Komponente ist eine verbindliche Schnittstelle (Interface) zum Rest der Software. Die Schnittstelle kann daher mit einem Vertrag zwischen der Komponente und dem Rest der Software verglichen werden. Durch die explizite Definition der Kontextabhängigkeiten wird deutlich, wie unabhängig eine Komponente tatsächlich von ihrer Umgebung ist. –Die Schnittstellen und wohldefinierte Kontextbedingungen ermöglichen die Wiederverwendung der Komponente. Je geringer die Kontextabhängigkeiten einer Komponente sind, desto weniger Anforderungen müssen für den Einsatz einer Komponente erfüllt werden. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 26 von xx

27 Komponentenbasierte Softwaresysteme sind komplexe Gebilde, ihre Erstellung erfordert ausgefeiltes Management –Einige Gründe sind »Software ist meist einzigartig »unter unterschiedlichen Randbedingungen zu entwickeln »erfordert die Integration von Altlasten »muss den schnellen technologischen Wandel berücksichtigen »muss auf Änderung der Anforderungen durch Anwender reagieren »soll unterschiedliche Fähigkeiten der Mitarbeiter optimal nutzen Prozessmodelle stellen Erfahrungen und Best Practice zur Verfügung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 27 von xx

28 Prozessmodelle W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 28 von xx Prozessmodelle als Teil des Management- Prozesses PM Projektmanagement SE Systementwicklung QS Qualitätssicherung KM Konfigurationsmanagement Prozessmodell Bei iterativem Vorgehen und bei Einschluss des Betriebes mehrfacher Durchlauf mit KM

29 Prozessmodelle Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 29 von xx Aktivitäten des Management-Prozesses -1- Planungsaktivitäten Ziele setzen Strategien und Taktiken entwickeln Termine festlegen Entscheidungen treffen Vorgehensmodell auswählen Risiko abschätzen Finanzen planen Prozessmodell

30 Prozessmodelle Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 30 von xx Aktivitäten des Management-Prozesses -2- Organisationsaktivitäten Identifizieren und Gruppieren der zu erledigenden Aufgaben (Rollen) Auswahl und Etablierung organisatorischer Strukturen Festlegen von Verantwortungs- bereichen und disziplinarischen Vollmachten Festlegen von Qualifikationsprofilen für Positionen Prozessmodell

31 Prozessmodelle Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 31 von xx Aktivitäten des Management-Prozesses -3- Personalaktivitäten Positionen besetzen Neues Personal einstellen und integrieren Aus- und Weiterbildung von Mitarbeitern Personalentwicklung planen Prozessmodell

32 Prozessmodelle Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 32 von xx Aktivitäten des Management-Prozesses -4- Leitungsaktivitäten Mitarbeiter führen und beaufsichtigen Kompetenzen delegieren Mitarbeiter motivieren Aktivitäten koordinieren Kommunikation unterstützen Konflikte lösen Innovationen einführen Prozessmodell

33 Prozessmodelle Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 33 von xx Aktivitäten des Management-Prozesses -5- Kontrollaktivitäten Prozess- und Produktstandards entwickeln und festlegen Berichts- und Kontrollwesen etablieren Prozesse und Produkte vermessen Korrekturaktivitäten initiieren Loben und Tadeln Prozessmodell

34 Prozessmodelle Was leisten Prozessmodelle im SE – 1 –Software Erstellungsprozess wird transparent »Vergabe von Zielen, Wegen, Mitteln, Aufgaben, Rollen –Software Erstellung wird überprüfbar »Erfüllung der Aufgabe »Erreichung der Ziele »Aufdeckung von Risiken »Beurteilung des Projektfortschrittes –Management von Ressourcen wird möglich »Kosten »Zeit »Personen –Erfahrungen werden gesammelt und wiederverwendbar »Tailoring von Workflows »Best Practice Effekt Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 34 von xx

35 Prozessmodelle Was leisten Prozessmodelle im SE – 2 –Prozessmodelle strukturieren den Vorgang der Software Erstellung »Definieren Aktivitäten »Legen deren Ergebnisse fest »Geben Empfehlungen für die Abarbeitung der Aktivitäten –Prozessmodelle müssen daher ausgewählt und angepasst werden »für jedes Projekt »für jedes Projektteam –Das in einem konkreten Projekt verwendete Prozessmodell charakterisiert die Komplexität und den Lösungsansatz im Projekt Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 35 von xx

36 Prozessmodelle Ziel: Qualitätsvolle Software –Prozessqualität »V-Modell als Rahmen für PM, SE, QS, KM »Wasserfallmodell als Prozessmodell für kleine Projekte »Der UP als best practice Modell für komponentenbasierte SE »Mischmodelle für die Praxis –Produktqualität »Testgetriebene Entwicklung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 36 von xx

37 Prozessmodelle Das V-Modell –Der Entwicklungsstandard für IT-Systeme des Bundes besteht aus drei Teilen: »Vorgehensmodell (Was ist zu tun?), »Methodenzuordnung (Wie ist etwas zu tun?) »Funktionale Werkzeuganforderungen (Womit ist etwas zu tun?) W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 37 von xx Der Kern des Standards ist die Beschreibung des IT- Entwicklungsprozesses als Vorgehensmodell, wofür abkürzend das Wort V-Modell benutzt wird. Dabei werden in dem Begriff V-Modell die Teile Methodenzuordnung und funktionale Werkzeuganforderungen mit eingeschlossen, weil diese als Ergänzung zum Vorgehensstandard zu verstehen sind. Im V-Modell wird der Entwicklungsprozess als eine Folge von Tätigkeiten, den Aktivitäten, und deren Ergebnisse, den Produkten, beschrieben. (aus Dröschel et al. Kap. 4, Ref. 31)

38 Prozessmodelle Das V-Modell –Zu jeder Aktivität existiert eine Aktivitätsbeschreibung als Arbeitsanleitung. Im zugehörigen Produktfluss wird angegeben »welche Produkte als Eingangsprodukte benötigt werden, »wo sie zuletzt bearbeitet wurden, »welche Produkte erzeugt oder modifiziert werden und »in welcher Folgeaktivität die erzeugten/modifizierten Produkte verwendet werden. –Dadurch wird der logische Ablauf des Vorgehens eindeutig festgelegt. –Die Inhalte der Produkte werden in den Produktmustern festgelegt. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 38 von xx

39 Prozessmodelle Das V-Modell –Der gesamte Prozess ist in Tätigkeitsbereiche untergliedert. –Im V-Modell werden diese als Submodelle beschrieben: »Die Systemerstellung (SE) erstellt das System bzw. die Softwareeinheiten. »Das Projektmanagement (PM) plant, initiiert und kontrolliert den Prozess und informiert die Ausführenden der übrigen Submodelle. »Die Qualitätssicherung (QS) gibt Qualitätsanforderungen, Prüffälle und Kriterien vor und unterstützt die Produkte bzw. den Prozess hinsichtlich der Einhaltung von Qualitätsanforderungen und Standard. »Das Konfigurationsmanagement (KM) verwaltet die Produkte. Es stellt sicher, dass die Produkte eindeutig identifizierbar sind und Produktänderungen nur kontrolliert durchgeführt werden. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 39 von xx

40 Prozessmodelle Das V-Modell –Komponenten »Submodelle sind charakterisiert durch Vorgehensweisen, Methoden und Werkzeuge. Das V-Modell unterscheidet die Submodelle Projektmanagement, Qualitätssicherung, Konfigurationsmanagement und Systemerstellung »Aktivitäten sind Aufgaben, die hinsichtlich ihrer Ergebnisse und Abwicklung genau spezifiziert sind. Aufgaben von Aktivitäten sind Erzeugen, Modifizieren (Zustandsänderung) und Manipulieren (Veränderung) von Produkten »Produkte sind das Ergebnis einer Aktivität. Produkte können sein Code, Entwicklungsdokumente, begleitende Dokumente (Pläne) etc. Produkte können die Zustände: geplant, in Bearbeitung, vorgelegt, akzeptiert annehmen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 40 von xx

41 Prozessmodelle Das V-Modell –Komponenten »Beschreibungsmuster stehen als Templates für Produkte und Listen der Aktivitäten zur Verfügung »Tailoring Anpassung an die Projekt- und Vorhabenseigenschaften W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 41 von xx

42 Prozessmodelle W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 42 von xx Quelle: V-Modell der Software-Entwicklung (Thaller: ISO 9001) Das V-Modell

43 Prozessmodelle Rational Unified Process (RUP) –Dem Rational Unified Process (RUP) liegt ein best practice objektorientiertes Modell zu Grunde. Der RUP definiert sich über Workflows, die parallel und in Phasen ablaufen. Innerhalb jeder Phase sind Iterationen und inkrementelle Verbesserungen möglich. –Zur Definition der Workflows stehen im RUP eine Reihe von Hilfsmitteln zur Verfügung (Schlüsselkonzepte), die miteinander wechselwirken. Zum Beispiel werden Aktivitäten von Workers erbracht, die dadurch Artefakte produzieren. Zur Gestaltung der Artefakte werden Guidelines und Templates zur Verfügung gestellt. Best Practice bedeutet die Verwendung auch kommerziell erprobter Ansätze zur Software Entwicklung und den Versuch aus Fehlern gescheiterter Projekte zu lern W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 43 von xx

44 Prozessmodelle Rational Unified Process (RUP) –4 Phasen des RUP »Konzeption »Entwurf »Realisierung »Einführung und Betrieb W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 44 von xx

45 Prozessmodelle RUP –Ziele und Aufgaben der Konzeptionsphase »Ziele: Schaffung von Planungs- und Entscheidungsgrundlagen »Aufgaben: Vorstudie zur Machbarkeit erstellen Definition des Projektzieles und Abgrenzung Erarbeitung, Bewertung, Empfehlung und Entscheidung über Realisierungsalternativen Überblick über Problembereich und Anforderungen Grobe Projektplanung (Iterationen etc.) Identifizierung der Projektrisiken W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 45 von xx

46 Prozessmodelle RUP –Ziele und Aufgaben der Entwurfsphase »Ziele: Erfassung der wichtigsten funktionalen und nichtfunktionalen Anforderungen Validierte, stabile und ausführbare Software-Architektur »Aufgaben: Entwicklung von Systemteilen mit hoher Priorität und hohem Risiko Use Case-Modell erstellen (Anforderungsanalyse) Festlegung der Anwendungsarchitektur Feinplanung der jeweiligen Iteration erstellen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 46 von xx

47 Prozessmodelle RUP –Ziele und Aufgaben der Realisierungsphase »Ziele: stabiles Produkt für die Auslieferung »Aufgaben: inkrementelle Entwicklung der Subsysteme und jeweilige Integration Test aller Komponenten, Schnittstellen, Dienste,... Dokumentation W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 47 von xx

48 Prozessmodelle RUP –Ziele und Aufgaben der Einführungs- und Betriebsphase »Ziele: Produkt in Betrieb nehmen Produkt betreiben »Aufgaben: Auslieferung Installation Schulung Wartung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 48 von xx

49 Prozessmodelle RUP –Phasen und Workflows W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 49 von xx Iterationen umfassen jeweils alle Workflows einer Phase Process Workflows Supporting Workflows Management Environment Business Modeling Implementation Test Analysis & Design Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Configuration Mgmt Requirements EntwurfEinführung Konzeptio n Realisierung

50 Prozessmodelle RUP –Iterationen »Wesentliches Kennzeichen des RUP ist sein iterativer Ansatz. »Das bedeutet, dass innerhalb jeder der vier Phasen diverse Iterationen möglich sind. »Jede Iteration entspricht einem kleinen Wasserfällchen. Das Konzept sieht dabei vor, dass jede Iteration mit einem ausführbaren und getesteten Release abgeschlossen wird. »Jede Iteration legt dabei unterschiedliche Schwerpunkte hinsichtlich des Workflows fest. Dies führt zum sogenannten iterativ-inkrementellen Vorgehen. W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 50 von xx

51 Prozessmodelle RUP –Iterationen »Erfahrung Anforderungen sind unvollständig wichtige Erkenntnisse werden erst im Laufe des Projektes gewonnen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 51 von xx Analyse Design Kodierung Test Iteration 1 Iteration 2 Iteration N

52 Modellierung Modellierung komplexer Realität mit Objekten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 52 von xx Entwicklung in mehreren Schritten - iterativ und mit situationsangepassten Verbesserungen - inkrementell Entwicklung in mehreren Schritten - iterativ und mit situationsangepassten Verbesserungen - inkrementell

53 Modellierung Werkzeug: Unified Modeling Language (UML) –Sprache / Notation zur Beschreibung von Objekten und ihren Beziehungen –UML stellt zur Verfügung: »ein Meta-Modell (grundlegende Modellierungskonzepte, Modellelemente und ihre Semantik) »eine graphische Notation zur Visualisierung des Meta-Modells »Richtlinien (Namenskoventionen, Anordnung von Symbolen usw.) –UML ist keine Methode, weil sie kein Vorgehensmodell definiert, dies geschieht beispielsweise mit dem Rational Unified Process –UML ist durch Verwendung von Stereotypen erweiterbar W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 53 von xx

54 Modellierung UML –UML ist für den gesamten Software-Lebenszyklus entwickelt worden –Verschiedene Sichten, die mit UML darstellbar sind: »Spezifikation(Nutzung) »Analyse »Entwurf »Implementierung »Betrieb W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 54 von xx DESIGN VIEW PROCESS VIEW DEPLOYMENT VIEW COMPONENT VIEW USE CASE VIEW USE CASE VIEW

55 Modellierung UML –Modellelemente »Use Cases zur Beschreibung der Anforderungen »Klassen zur Beschreibung der Objekte »Beziehungen zum Bau von Systemen »Diagramme zur Beschreibung verschiedener Sichten auf ein System –Alle Elemente können rekursiv eingesetzt werden »Aus Klassen werden Pakete und Komponenten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 55 von xx

56 Diagrammtypen der UML –Sichten werden über Diagramme graphisch beschrieben –Die wichtigsten Diagramme »Use Case-Diagramm »Klassendiagramm »Paketdiagramm »Komponenten-Diagramm –Weitere Diagramme sind z.B. »Interaktionsdiagramm (Sequenzdiagramm, Kollaborationsdiagramm) »Zustandsdiagramm »Deployment-Diagramm Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 56 von xx

57 UML: Use Case Diagramm –Beschreibt Benutzungsszenarien eines Systems (Anwendungsfälle) –WER (Akteur) tut WAS (Use Case) –Geeignet für: »Anforderungsspezifikation »Kommunikation mit dem Auftraggeber »Geschäftsprozessmodellierung »Workflowmodellierung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 57 von xx

58 UML: Elemente eines Use Case Diagramms W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 58 von xx Anwendungsfall A ist eine Variation vom Anwendungsfall B (Generalisierung) Akteur Anwendungsfall Der Anwendungsfall A ist ein Bestandteil vom Anwendungsfall B Der Anwendungsfall A erweitert an einer bestimmten Stelle den Anwendungsfall B

59 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 59 von xx StammdatenabfrageMetadatenabfrage Bereitstellung des Filters zur Messwertabfrage Anforderung von Messwerten > Zustellen von Messwerten Abholen von Messwerten > ABR-Service auf ZDH: Request Broker ABR-Service auf ZDH: Datenauslieferung ZDH-Service auf ABR: Datenanfrage ZDH-Service auf ABR: Messwertbeschaffung * ** * * * * * UML: Beispiel für ein Use Case Diagramm

60 UML: Klassen-Diagramm –Zentrales Element der UML und der objektorientierten Softwareentwicklung –Darstellungen von Klassen und Objekten mit Beziehungen, Methoden und Attributen –Viele Details darstellbar, z.B.: »spezielle Eigenschaften einer Klasse (abstrakt, interface) »Kardinalitäten der Beziehungen »Navigationsfähigkeit »usw. –Klasse: Grundbaustein objektorientierter Systeme –Komponenten einer Klasse »Beschreibung »Eigenschaften (Attribute) »Operationen Name Universität Stuttgart - 1XX-123 – Modulthema - Feb-14Seite 60 von xx

61 UML: Elemente eines Klassen-Diagramms W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 61 von xx Aggregation: Klasse A beinhaltet die Klasse B, B ist Teil von A Vererbung: Klasse A erbt von der Klasse B Klasse Abhängigkeit: Klasse A hängt von der Klasse B ab - Änderung in B erfordert Änderung in A Assoziation: Klassen A und B stehen in einer Beziehung zu einander. Instanzen sind Objektverbindungen, die durch die Assoziation beschrieben werden

62 UML: Beziehungen zwischen Klassen –Objekte müssen modifiziert werden »dies geschieht über Vererbung –Objekte müssen Methoden anderer Klassen verwenden können »dies geschieht über Assoziationen –Objekte müssen zur Bildung komplexerer Objekte einsetzbar sein »dies geschieht über Aggregationen –Ist die Verbindung nur unter Einschränkungen möglich, so müssen ihr eigene Attribute zugeordnet werden »dies geschieht über Abhängigkeiten W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 62 von xx

63 UML: Beispiel für ein Klassen-Diagramm W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 63 von xx get_air_concentration Washout_parameter get_washed_out _activity() Airconcentration Dry_deposition Wet_deposition get_deposited_activity Deposition_parameter Assoziationen

64 UML: Methoden zum Finden von Objekten und Klassen –Es gibt kein einheitliches Vorgehensmodell für die Modellierung mit Objekten. –Die Auswahl einer Modellierungsmethode ist eine projektspezifische Entscheidung und kann - abhängig von der Problemstellung - sehr unterschiedlich ausfallen. –Für Ingenieurprobleme hat sich eine Top-down Analyse analog der strukturierten Analyse bewährt. Sie beginnt in der Regel mit einer Use Case-Modellierung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 64 von xx Prozeßdiagramm Jacobson Use-Case- Modellierung Zustandsmodellierun g Klassen-/Objekt- modellierung Klassen-/Objekt- modellierung Prozessdiagramm Interaktionsmodellierung Subsystemmodellierun g CRC-Cards ClassResponsibility Collaboration Moduldiagramme Booch, Rumbaugh Booch, Rumbaugh Booch, Rumbaugh Shlaer, Mellor Booch Use-Case-Modellierung

65 UML: Methoden zum Finden von Objekten und Klassen –CRC - (Class - Responsibility - Collaboration) Methode » Hauptwortmethode: Hauptwörter ergeben Klassen »Aber Achtung: Hauptwörter, die eher Werte haben (Länge, Breite, etc.), sind meist Attribute evtl. viel zu viele Klassen evtl. wichtige Klassen vergessen –Formularanalysen (Altsysteme) –Standardbegriffe wie Kunde, Adresse, Vertrag, etc. –Rollen als Klassen –(Geschäfts-)Prozesse (Abläufe im Modell) als Klassen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 65 von xx

66 UML: Paket-Diagramm –Strukturierung eines Software-Systems in größere Einheiten als Klassen –Vermittelt einen Grobüberblick über ein Software-System –Wichtig für Darstellung von Abhängigkeiten auf höherer Ebene W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 66 von xx

67 UML: Elemente eines Paket-Diagramms W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 67 von xx Paket Abhängigkeit: Paket A hängt vom Paket B ab

68 UML: Beispiel für ein Paketdiagramm W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 68 von xx Freisetzung Transport Dosisberechnung

69 UML: Komponenten-Diagramm –Eine Komponente ist ein unabhängiger, austauschbarer Teil eines Softwaresystems, die eine sinnvolle Aufgabe im Kontext einer Softwarearchitektur erledigt. –Eine Komponente ist auch eine standardisierte, wieder- verwendbare und im Vorfeld implementierte Einheit, welche benutzt wird, um Konstrukte einer Programmiersprache zu erweitern und Softwareanwendungen zu bauen. –Eine Komponente kann mehrere Klienten haben, kennt aber nicht den Kontext in dem sie benutzt wird –In der UML werden Implementierungskomponenten (technische Komponenten) direkt unterstützt als »Komponenten in Form von Quellcode »Komponenten in Form von Binärcode »Komponenten in Form von ausführbaren Code W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 69 von xx

70 UML: Elemente eines Komponenten-Diagramms W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 70 von xx Komponente Interface (Schnittstelle) Die Komponente A realisiert das Interface A Die Komponente A hängt vom Interface der Komponente B ab.

71 UML: Beispiel für ein Komponenten-Diagramm W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 71 von xx ZDH- Service Windfeld- Berechnung

72 UML: Sequenz-Diagramm –Darstellung von dynamischen Abläufen –Kommunikation zwischen Objekten –Geeignet: Wenn (viele) Botschaften zwischen wenigen Objekten ausgetauscht werden W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 72 von xx

73 UML: Darstellung eines Sequenz-Diagramms W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 73 von xx Object 2 Object 1 Object 3 Object 4 Object 5 Object6 Method 1 Method 2 Method 3 Method 5 Method 4

74 UML: Kollaborations-Diagramm –Dieselbe Information wie im Sequenz-Diagramm »Darstellung von dynamischen Abläufen »Kommunikation zwischen Objekten –Geeignet: Wenn wenige Botschaften zwischen vielen Objekten ausgetauscht werden –evtl. später auch für Debugging von Programmen W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 74 von xx

75 UML: Darstellung eines Kollaborations-Diagramms W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 75 von xx Object 3 Object 1 Object 2 1: Method 1 2: Method 2 Obejct 4 Object 5 4: Method 4 Object 6 3: Method 3


Herunterladen ppt "W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Feb-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering."

Ähnliche Präsentationen


Google-Anzeigen