Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Simulation der Ausbreitung radioaktiver Schadstoffe

Ähnliche Präsentationen


Präsentation zum Thema: "Simulation der Ausbreitung radioaktiver Schadstoffe"—  Präsentation transkript:

1 Simulation der Ausbreitung radioaktiver Schadstoffe
Software Engineering W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Mrz-17

2 Inhalte der Vorlesung 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 W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Mrz-17

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

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

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

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

7 Simulationssysteme Herausforderung Lösungsansatz
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 - Mrz-17

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

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

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

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

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

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

14 Simulationssysteme Qualitätssicherung DIN ISO 9000
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 - Mrz-17

15 Qualität des Produktes Nachweis durch Prüfung
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 Merkmale und Eigenschaften des Produktes Qualität des Produktes Nachweis durch Prüfung Anforderungen und/oder Erwartungen an das Produkt PROZESS Anweisungen Ausführung Prozessqualität W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

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

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

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-Jo“Vorgehensweise Pragmatische Verbindung von Top-Down-und Bottom-up-Methode W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

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

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

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

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

27 Prozessmodelle stellen Erfahrungen und Best Practice zur Verfügung
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 - Mrz-17

28 Personal Leitung Kontrolle
Prozessmodelle Prozessmodelle als Teil des Management-Prozesses Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SE QS KM Personal Leitung Kontrolle Durchführung PM Projektmanagement SE Systementwicklung QS Qualitätssicherung KM Konfigurationsmanagement Bei iterativem Vorgehen und bei Einschluss des Betriebes mehrfacher Durchlauf mit KM W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

29 Aktivitäten des Management-Prozesses -1-
Prozessmodelle Aktivitäten des Management-Prozesses -1- Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SE QS KM Personal Leitung Kontrolle Durchführung Planungsaktivitäten Ziele setzen Strategien und Taktiken entwickeln Termine festlegen Entscheidungen treffen Vorgehensmodell auswählen Risiko abschätzen Finanzen planen Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

30 Aktivitäten des Management-Prozesses -2-
Prozessmodelle Aktivitäten des Management-Prozesses -2- Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SE QS KM Personal Leitung Kontrolle Durchführung 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 Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

31 Aktivitäten des Management-Prozesses -3-
Prozessmodelle Aktivitäten des Management-Prozesses -3- Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SE QS KM Personal Leitung Kontrolle Durchführung Personalaktivitäten Positionen besetzen Neues Personal einstellen und integrieren Aus- und Weiterbildung von Mitarbeitern Personalentwicklung planen Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

32 Aktivitäten des Management-Prozesses -4-
Prozessmodelle Aktivitäten des Management-Prozesses -4- Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SE QS KM Personal Leitung Kontrolle Durchführung Leitungsaktivitäten Mitarbeiter führen und beaufsichtigen Kompetenzen delegieren Mitarbeiter motivieren Aktivitäten koordinieren Kommunikation unterstützen Konflikte lösen Innovationen einführen Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

33 Aktivitäten des Management-Prozesses -5-
Prozessmodelle Aktivitäten des Management-Prozesses -5- Analyse Konzept- entwicklung Planung Prozessmodell Organisation PM SE QS KM Personal Leitung Kontrolle Durchführung Kontrollaktivitäten Prozess- und Produktstandards entwickeln und festlegen Berichts- und Kontrollwesen etablieren Prozesse und Produkte vermessen Korrekturaktivitäten initiieren Loben und Tadeln Name Universität Stuttgart - 1XX-123 – Modulthema - Mrz-17

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

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

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

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?) 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) W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

40 Prozessmodelle Das V-Modell Komponenten Submodelle Aktivitäten
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 - Mrz-17

41 Prozessmodelle Das V-Modell Komponenten Beschreibungsmuster Tailoring
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 - Mrz-17

42 Prozessmodelle Das V-Modell
Quelle: V-Modell der Software-Entwicklung (Thaller: ISO 9001) W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

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

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

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

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

49 Preliminary Iteration(s)
Prozessmodelle RUP Phasen und Workflows 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 Entwurf Einführung Konzeption Realisierung Iterationen umfassen jeweils alle Workflows einer Phase W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

52 Modellierung Modellierung komplexer Realität mit Objekten
Entwicklung in mehreren Schritten iterativ und mit situationsangepassten Verbesserungen - inkrementell W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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 DESIGN VIEW PROCESS VIEW DEPLOYMENT VIEW COMPONENT VIEW USE CASE VIEW W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

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

58 UML: Elemente eines Use Case Diagramms
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 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

59 UML: Beispiel für ein Use Case Diagramm
Stammdatenabfrage Metadatenabfrage Bereitstellung des Filters zur Messwertabfrage Anforderung von Messwerten <<uses>> <<extends>> Zustellen von Messwerten Abholen von Messwerten ABR-Service auf ZDH: Request Broker Datenauslieferung ZDH-Service auf ABR: Datenanfrage Messwertbeschaffung * W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

61 UML: Elemente eines Klassen-Diagramms
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 Aggregation: Klasse A beinhaltet die Klasse B, B ist Teil von A W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

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 Jacobson Booch, Rumbaugh Use-Case-Modellierung Use-Case-Modellierung Zustandsmodellierung Zustandsmodellierung Booch, Rumbaugh CRC-Cards ClassResponsibility Collaboration Klassen-/Objekt- modellierung Interaktionsmodellierung Booch, Rumbaugh Prozessdiagramm Subsystemmodellierung Subsystemmodellierung Moduldiagramme Prozeßdiagramm Booch Shlaer, Mellor Booch W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

67 UML: Elemente eines Paket-Diagramms
Abhängigkeit: Paket A hängt vom Paket B ab W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

68 UML: Beispiel für ein Paketdiagramm
Dosisberechnung Transport Freisetzung W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

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

71 UML: Beispiel für ein Komponenten-Diagramm
Windfeld- Berechnung ZDH- Service W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

73 UML: Darstellung eines Sequenz-Diagramms
Object 1 Object 2 Object 3 Object 4 Object 5 Object6 Method 1 Method 2 Method 3 Method 4 Method 5 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17

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

75 UML: Darstellung eines Kollaborations-Diagramms
Object 1 1: Method 1 Object 2 2: Method 2 3: Method 3 Object 3 Object 6 4: Method 4 Object 5 Obejct 4 W. Scheuermann Universität Stuttgart - Ziel und Rahmenbedingungen - Mrz-17


Herunterladen ppt "Simulation der Ausbreitung radioaktiver Schadstoffe"

Ähnliche Präsentationen


Google-Anzeigen