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

of 75/75
W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - 11.06.22 Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering
  • date post

    05-Apr-2015
  • Category

    Documents

  • view

    121
  • download

    2

Embed Size (px)

Transcript of W. Scheuermann Universität Stuttgart - Kontext der Ausbreitung - Feb-14Seite 1 von 23 Simulation...

  • Folie 1
  • W. Scheuermann Universitt Stuttgart - Kontext der Ausbreitung - Feb-14Seite 1 von 23 Simulation der Ausbreitung radioaktiver Schadstoffe Software Engineering
  • Folie 2
  • Inhalte der Vorlesung W. Scheuermann Universitt Stuttgart - Kontext der Ausbreitung - Feb-14Seite 2 von 23 Ziele und Kontext von Ausbreitungsrechnungen Ausbreitungsphnomene, Modellierung physikalischer Prozesse Freisetzung, Zerfall Topographie, Gelndemodelle, Koordinatensysteme Windfeldmodelle Transportmodelle Dosisberechnung, chemische Prozesse in der Atmosphre Simulationssysteme Softwareparadigmen / Frameworks Werkzeuge zur Modellierung (UML) Architektur von ABR_V2.0 Modelle in der ABR_V2.0 Benchmarks / Validierung
  • Folie 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 Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 3 von xx
  • Folie 4
  • Simulationssysteme Rahmenbedingungen: Einbindung in eine bestehende Infrastruktur Systemumgebung Rechner Betriebssystem Netzwerk Organisation Wer darf wann was W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 4 von xx
  • Folie 5
  • Simulationssysteme Definition Ein Simulationsmodell (-system) ist ein spezielles Modell, dessen Gegenstand, Inhalt und Darstellung fr Zwecke der Simulation konstruiert wird Dabei werden nur diejenigen Merkmale des Systems modelliert, die fr eine konkret zu lsende Fragestellung von Bedeutung sind. Andere Merkmale hingegen, die fr die Fragestellung von minderer Bedeutung sind, werden dabei vernachlssigt. W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 5 von xx
  • Folie 6
  • Simulationssysteme Charakteristika Dienen einem Zweck => Kontext Sind nur in definierten Grenzen einsetzbar Sind hoch komplex Gesamtsystem mehr als Summe von Teilen Systembeitrge aus verschiedenen Bereichen Erstellung interdisziplinr multi physics Systemerscheinung benutzerangepasst verschiedene Sichten ntig W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 6 von xx
  • Folie 7
  • Simulationssysteme Herausforderung Beherrschung der Komplexitt Einhaltung zeitlicher und finanzieller Randbedingungen Lsungsansatz Methoden des Software Engineerings Modellierung Prozesssteuerung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 7 von xx
  • Folie 8
  • Simulationssysteme Software Engineering zielt auf die ingenieurmige Entwicklung, Wartung, Anpassung und Weiterentwicklung groer Softwaresysteme unter Verwendung bewhrter, systematischer Vorgehensweisen, Prinzipien, Methoden und Werkzeuge. "Systematisch" heit, dass grundlegende Ingenieurprinzipien zur Beherrschung von Komplexitt eingesetzt werden. "Bewhrt" heit, dass Erfahrungen ber die Wirksamkeit, Strken und Schwchen der verwendeten Anstze 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 8 von xx
  • Folie 9
  • Simulationssysteme Anstze zur Beherrschung der Komplexitt 3 S Simplifizierung durch Strukturierung und Weglassen unntiger Teile Spezialisierung auf rumlich und zeitlich begrenzte Teilaufgaben Standardisierung der Schnittstellen fr die Integration und Feststellung der Verantwortlichkeit und Qualitt Basis ist die Technik der inhaltlichen und zeitlichen Strukturierung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 9 von xx
  • Folie 10
  • Simulationssysteme Strukturierung mit den Elementen Strukturierung der Systeme Ganzes und Teile Allgemeines und spezielles Diversifikation der Funktionalitten fachlich + zeitlich Verbergen von Details hinter Schnittstellen Standardisierung durch Formalisierung der Beschreibungen - Produktmodelle Formalisierung der Funktionen - Dienste und Komponenten Wiederverwendung und Weiterentwicklung bewhrter Komponenten W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 10 von xx
  • Folie 11
  • Simulationssysteme Qualittssicherung Projektmanagement, Prozessberwachung, Produktberprfung erfordern einen Arbeitsstil, der durch die 3 K geprgt wird: Kooperation, Kommunikation und Koordination W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 11 von xx
  • Folie 12
  • Simulationssysteme Spezialisierung erfordert Standardisierung Standardisierung der Schnittstellen ermglicht Integration Standardisierung der Prozesse ermglicht Qualitt Standardisierung der Ablufe ermglicht Effizienz Standardisierung ist eine weitere Voraussetzung fr die Konzentration auf: Kooperation Kommunikation und Koordination W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 12 von xx
  • Folie 13
  • Simulationssysteme Qualittssicherung als Basis des kooperativen Arbeitens Qualitt kann man nicht in ein Produkt hineinprfen; sie muss hineinkonzipiert, - konstruiert und - produziert werden Die Qualitt der Produkte eines Unternehmens bestimmt dessen Image Am Qualittsgeschehen sind alle Abteilungen beteiligt Systematische Qualittsplanung ist die Voraussetzung einer erfolgreichen und wirtschaftlichen Verwirklichung der Qualittsziele Guter Informationsfluss zwischen allen Beteiligten verhtet Fehlentscheidungen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 13 von xx
  • Folie 14
  • Simulationssysteme Qualittssicherung Produktprfung ist gut, Prozessberwachung besser, beherrschte Fertigung am besten. Richtig verstandene Selbstprfung am Arbeitsplatz vermeidet Ausschuss und Fehlerfolgekosten. DIN ISO 9000 Qualittsmanagement- und Qualittssicherungsnormen, Leitfaden zur Auswahl und Anwendung Betont: Prozessqualitt und Kundenzufriedenheit Qualittssicherungssystem und seine Funktionsfhigkeit mssen im Rahmen eines Audits berprft werden W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 14 von xx
  • Folie 15
  • Simulationssysteme Prozessqualitt und Produktqualitt nach ISO 9000 Grundannahmen Qualittsziele werden whrend der Konzeptfindung vorgegeben. Der Entwicklungsprozess trgt wesentlich zur Qualitt des Produktes bei. Die Qualitt des Entwicklungsprozesses kann definiert gemessen und verbessert werden. Die Fehlerbehebung ist teuer und immer nur letzter Ausweg W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 15 von xx Merkmale und Eigenschaften des Produktes Qualitt des Produktes Nachweis durch Prfung Anforderungen und/oder Erwartungen an das Produkt PROZESS AnweisungenAusfhrung Prozessqualitt
  • Folie 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 16 von xx
  • Folie 17
  • Simulationssysteme W. Scheuermann Universitt 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
  • Folie 18
  • Simulationssysteme Funktionale Zerlegung Modularisierung Wie finden man Module ? Sprachliche modulare Einheiten Module mssen zu syntaktischen Einheiten der Sprache passen. Minimum an Schnittstellen Module sollten mglichst wenig untereinander kommunizieren. Schwache Kopplung Bei der Kommunikation sollte so wenig Information wie mglich ausgetauscht werden W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 18 von xx
  • Folie 19
  • Simulationssysteme Funktionale Zerlegung Modularisierung Was charakterisiert Module ? Explizit erkennbare Schnittstelle Geheimnisprinzip (Information Hiding) Abgeschlossenheit Handhabbarkeit Isolierte Prfbarkeit Integrierbarkeit Planbarkeit Lokalitt der Entwurfsentscheidung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 19 von xx
  • Folie 20
  • Simulationssysteme Funktionale Zerlegung Anstze zum Auffinden von Modulen Bottom-up Vorgehensweise Suche nach atomaren Teilen aus denen das System zusammengesetzt wird Schrittweise Abstraktion und Kombination bekannter Einzelelemente zu greren 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 20 von xx
  • Folie 21
  • Simulationssysteme Funktionale Zerlegung Bottum-up Vorteile: Konkreter Ausgangspunkt garantiert solide Basis fr die Softwareentwicklung Suche nach vorhandenen Teillsungen wird begnstigt Gut geeignet fr das Testen Nachteile: Schwierigkeiten, Anwendungsbereich als Ziel tatschlich zu erreichen Notwendigkeit einer breiten Basis auf unteren Ebenen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 21 von xx
  • Folie 22
  • Simulationssysteme Funktionale Zerlegung Top-down Vorteile: Anwendungsbereich steht im Mittelpunkt der Softwareentwicklung Vollstndige, exakte Spezifikationen fhren genau zum gewnschten System Die Gesamtbersicht erleichtert die Bildung geeigneter Abstraktionsebenen und fhrt zu einer guten Systemstruktur Nachteile: Gute Fhigkeiten zum abstrakten Denken erforderlich Realisierungsprobleme werden erst spt erkannt Ungeeignet fr das Testen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 22 von xx
  • Folie 23
  • Simulationssysteme Funktionale Zerlegung Jo-Jo Vorteile: Flexible Anpassung der Vorgehensweise an die sich ergebende Situationen Reduzierte Anforderungen an das Abstraktionsvermgen Nachteile: Willkrliche Entscheidung, wann Wechsel der Bearbeitungsrichtung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 23 von xx
  • Folie 24
  • Grenzen der klassischen Vorgehensweide Zeitlicher Ablauf zu starr Festgelegte Abfolge der Ttigkeiten Kaum iterative Verbesserungen mglich Hoher nderungsaufwand Neuer Ansatz Komponentenbasierte Systeme W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 24 von xx
  • Folie 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 verknpft und ausgefhrt 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 abhngig vom jeweiligen Komponentenmodell. W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 25 von xx
  • Folie 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 Kontextabhngigkeiten wird deutlich, wie unabhngig eine Komponente tatschlich von ihrer Umgebung ist. Die Schnittstellen und wohldefinierte Kontextbedingungen ermglichen die Wiederverwendung der Komponente. Je geringer die Kontextabhngigkeiten einer Komponente sind, desto weniger Anforderungen mssen fr den Einsatz einer Komponente erfllt werden. W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 26 von xx
  • Folie 27
  • Komponentenbasierte Softwaresysteme sind komplexe Gebilde, ihre Erstellung erfordert ausgefeiltes Management Einige Grnde sind Software ist meist einzigartig unter unterschiedlichen Randbedingungen zu entwickeln erfordert die Integration von Altlasten muss den schnellen technologischen Wandel bercksichtigen muss auf nderung der Anforderungen durch Anwender reagieren soll unterschiedliche Fhigkeiten der Mitarbeiter optimal nutzen Prozessmodelle stellen Erfahrungen und Best Practice zur Verfgung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 27 von xx
  • Folie 28
  • Prozessmodelle W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 28 von xx Prozessmodelle als Teil des Management- Prozesses PM Projektmanagement SE Systementwicklung QS Qualittssicherung KM Konfigurationsmanagement Prozessmodell Bei iterativem Vorgehen und bei Einschluss des Betriebes mehrfacher Durchlauf mit KM
  • Folie 29
  • Prozessmodelle Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 29 von xx Aktivitten des Management-Prozesses -1- Planungsaktivitten Ziele setzen Strategien und Taktiken entwickeln Termine festlegen Entscheidungen treffen Vorgehensmodell auswhlen Risiko abschtzen Finanzen planen Prozessmodell
  • Folie 30
  • Prozessmodelle Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 30 von xx Aktivitten des Management-Prozesses -2- Organisationsaktivitten Identifizieren und Gruppieren der zu erledigenden Aufgaben (Rollen) Auswahl und Etablierung organisatorischer Strukturen Festlegen von Verantwortungs- bereichen und disziplinarischen Vollmachten Festlegen von Qualifikationsprofilen fr Positionen Prozessmodell
  • Folie 31
  • Prozessmodelle Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 31 von xx Aktivitten des Management-Prozesses -3- Personalaktivitten Positionen besetzen Neues Personal einstellen und integrieren Aus- und Weiterbildung von Mitarbeitern Personalentwicklung planen Prozessmodell
  • Folie 32
  • Prozessmodelle Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 32 von xx Aktivitten des Management-Prozesses -4- Leitungsaktivitten Mitarbeiter fhren und beaufsichtigen Kompetenzen delegieren Mitarbeiter motivieren Aktivitten koordinieren Kommunikation untersttzen Konflikte lsen Innovationen einfhren Prozessmodell
  • Folie 33
  • Prozessmodelle Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 33 von xx Aktivitten des Management-Prozesses -5- Kontrollaktivitten Prozess- und Produktstandards entwickeln und festlegen Berichts- und Kontrollwesen etablieren Prozesse und Produkte vermessen Korrekturaktivitten initiieren Loben und Tadeln Prozessmodell
  • Folie 34
  • Prozessmodelle Was leisten Prozessmodelle im SE 1 Software Erstellungsprozess wird transparent Vergabe von Zielen, Wegen, Mitteln, Aufgaben, Rollen Software Erstellung wird berprfbar Erfllung der Aufgabe Erreichung der Ziele Aufdeckung von Risiken Beurteilung des Projektfortschrittes Management von Ressourcen wird mglich Kosten Zeit Personen Erfahrungen werden gesammelt und wiederverwendbar Tailoring von Workflows Best Practice Effekt Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 34 von xx
  • Folie 35
  • Prozessmodelle Was leisten Prozessmodelle im SE 2 Prozessmodelle strukturieren den Vorgang der Software Erstellung Definieren Aktivitten Legen deren Ergebnisse fest Geben Empfehlungen fr die Abarbeitung der Aktivitten Prozessmodelle mssen daher ausgewhlt und angepasst werden fr jedes Projekt fr jedes Projektteam Das in einem konkreten Projekt verwendete Prozessmodell charakterisiert die Komplexitt und den Lsungsansatz im Projekt Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 35 von xx
  • Folie 36
  • Prozessmodelle Ziel: Qualittsvolle Software Prozessqualitt V-Modell als Rahmen fr PM, SE, QS, KM Wasserfallmodell als Prozessmodell fr kleine Projekte Der UP als best practice Modell fr komponentenbasierte SE Mischmodelle fr die Praxis Produktqualitt Testgetriebene Entwicklung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 36 von xx
  • Folie 37
  • Prozessmodelle Das V-Modell Der Entwicklungsstandard fr 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 37 von xx Der Kern des Standards ist die Beschreibung des IT- Entwicklungsprozesses als Vorgehensmodell, wofr abkrzend das Wort V-Modell benutzt wird. Dabei werden in dem Begriff V-Modell die Teile Methodenzuordnung und funktionale Werkzeuganforderungen mit eingeschlossen, weil diese als Ergnzung zum Vorgehensstandard zu verstehen sind. Im V-Modell wird der Entwicklungsprozess als eine Folge von Ttigkeiten, den Aktivitten, und deren Ergebnisse, den Produkten, beschrieben. (aus Drschel et al. Kap. 4, Ref. 31)
  • Folie 38
  • Prozessmodelle Das V-Modell Zu jeder Aktivitt existiert eine Aktivittsbeschreibung als Arbeitsanleitung. Im zugehrigen Produktfluss wird angegeben welche Produkte als Eingangsprodukte bentigt werden, wo sie zuletzt bearbeitet wurden, welche Produkte erzeugt oder modifiziert werden und in welcher Folgeaktivitt 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 38 von xx
  • Folie 39
  • Prozessmodelle Das V-Modell Der gesamte Prozess ist in Ttigkeitsbereiche 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 Ausfhrenden der brigen Submodelle. Die Qualittssicherung (QS) gibt Qualittsanforderungen, Prfflle und Kriterien vor und untersttzt die Produkte bzw. den Prozess hinsichtlich der Einhaltung von Qualittsanforderungen und Standard. Das Konfigurationsmanagement (KM) verwaltet die Produkte. Es stellt sicher, dass die Produkte eindeutig identifizierbar sind und Produktnderungen nur kontrolliert durchgefhrt werden. W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 39 von xx
  • Folie 40
  • Prozessmodelle Das V-Modell Komponenten Submodelle sind charakterisiert durch Vorgehensweisen, Methoden und Werkzeuge. Das V-Modell unterscheidet die Submodelle Projektmanagement, Qualittssicherung, Konfigurationsmanagement und Systemerstellung Aktivitten sind Aufgaben, die hinsichtlich ihrer Ergebnisse und Abwicklung genau spezifiziert sind. Aufgaben von Aktivitten sind Erzeugen, Modifizieren (Zustandsnderung) und Manipulieren (Vernderung) von Produkten Produkte sind das Ergebnis einer Aktivitt. Produkte knnen sein Code, Entwicklungsdokumente, begleitende Dokumente (Plne) etc. Produkte knnen die Zustnde: geplant, in Bearbeitung, vorgelegt, akzeptiert annehmen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 40 von xx
  • Folie 41
  • Prozessmodelle Das V-Modell Komponenten Beschreibungsmuster stehen als Templates fr Produkte und Listen der Aktivitten zur Verfgung Tailoring Anpassung an die Projekt- und Vorhabenseigenschaften W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 41 von xx
  • Folie 42
  • Prozessmodelle W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 42 von xx Quelle: V-Modell der Software-Entwicklung (Thaller: ISO 9001) Das V-Modell
  • Folie 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 mglich. Zur Definition der Workflows stehen im RUP eine Reihe von Hilfsmitteln zur Verfgung (Schlsselkonzepte), die miteinander wechselwirken. Zum Beispiel werden Aktivitten von Workers erbracht, die dadurch Artefakte produzieren. Zur Gestaltung der Artefakte werden Guidelines und Templates zur Verfgung gestellt. Best Practice bedeutet die Verwendung auch kommerziell erprobter Anstze zur Software Entwicklung und den Versuch aus Fehlern gescheiterter Projekte zu lern W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 43 von xx
  • Folie 44
  • Prozessmodelle Rational Unified Process (RUP) 4 Phasen des RUP Konzeption Entwurf Realisierung Einfhrung und Betrieb W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 44 von xx
  • Folie 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 45 von xx
  • Folie 46
  • Prozessmodelle RUP Ziele und Aufgaben der Entwurfsphase Ziele: Erfassung der wichtigsten funktionalen und nichtfunktionalen Anforderungen Validierte, stabile und ausfhrbare Software-Architektur Aufgaben: Entwicklung von Systemteilen mit hoher Prioritt und hohem Risiko Use Case-Modell erstellen (Anforderungsanalyse) Festlegung der Anwendungsarchitektur Feinplanung der jeweiligen Iteration erstellen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 46 von xx
  • Folie 47
  • Prozessmodelle RUP Ziele und Aufgaben der Realisierungsphase Ziele: stabiles Produkt fr die Auslieferung Aufgaben: inkrementelle Entwicklung der Subsysteme und jeweilige Integration Test aller Komponenten, Schnittstellen, Dienste,... Dokumentation W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 47 von xx
  • Folie 48
  • Prozessmodelle RUP Ziele und Aufgaben der Einfhrungs- und Betriebsphase Ziele: Produkt in Betrieb nehmen Produkt betreiben Aufgaben: Auslieferung Installation Schulung Wartung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 48 von xx
  • Folie 49
  • Prozessmodelle RUP Phasen und Workflows W. Scheuermann Universitt 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 EntwurfEinfhrung Konzeptio n Realisierung
  • Folie 50
  • Prozessmodelle RUP Iterationen Wesentliches Kennzeichen des RUP ist sein iterativer Ansatz. Das bedeutet, dass innerhalb jeder der vier Phasen diverse Iterationen mglich sind. Jede Iteration entspricht einem kleinen Wasserfllchen. Das Konzept sieht dabei vor, dass jede Iteration mit einem ausfhrbaren und getesteten Release abgeschlossen wird. Jede Iteration legt dabei unterschiedliche Schwerpunkte hinsichtlich des Workflows fest. Dies fhrt zum sogenannten iterativ-inkrementellen Vorgehen. W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 50 von xx
  • Folie 51
  • Prozessmodelle RUP Iterationen Erfahrung Anforderungen sind unvollstndig wichtige Erkenntnisse werden erst im Laufe des Projektes gewonnen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 51 von xx Analyse Design Kodierung Test Iteration 1 Iteration 2 Iteration N
  • Folie 52
  • Modellierung Modellierung komplexer Realitt mit Objekten W. Scheuermann Universitt 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
  • Folie 53
  • Modellierung Werkzeug: Unified Modeling Language (UML) Sprache / Notation zur Beschreibung von Objekten und ihren Beziehungen UML stellt zur Verfgung: 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 Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 53 von xx
  • Folie 54
  • Modellierung UML UML ist fr den gesamten Software-Lebenszyklus entwickelt worden Verschiedene Sichten, die mit UML darstellbar sind: Spezifikation(Nutzung) Analyse Entwurf Implementierung Betrieb W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 54 von xx DESIGN VIEW PROCESS VIEW DEPLOYMENT VIEW COMPONENT VIEW USE CASE VIEW USE CASE VIEW
  • Folie 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 knnen rekursiv eingesetzt werden Aus Klassen werden Pakete und Komponenten W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 55 von xx
  • Folie 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 Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 56 von xx
  • Folie 57
  • UML: Use Case Diagramm Beschreibt Benutzungsszenarien eines Systems (Anwendungsflle) WER (Akteur) tut WAS (Use Case) Geeignet fr: Anforderungsspezifikation Kommunikation mit dem Auftraggeber Geschftsprozessmodellierung Workflowmodellierung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 57 von xx
  • Folie 58
  • UML: Elemente eines Use Case Diagramms W. Scheuermann Universitt 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
  • Folie 59
  • W. Scheuermann Universitt 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 fr ein Use Case Diagramm
  • Folie 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) Kardinalitten der Beziehungen Navigationsfhigkeit usw. Klasse: Grundbaustein objektorientierter Systeme Komponenten einer Klasse Beschreibung Eigenschaften (Attribute) Operationen Name Universitt Stuttgart - 1XX-123 Modulthema - Feb-14Seite 60 von xx
  • Folie 61
  • UML: Elemente eines Klassen-Diagramms W. Scheuermann Universitt 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 Abhngigkeit: Klasse A hngt 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
  • Folie 62
  • UML: Beziehungen zwischen Klassen Objekte mssen modifiziert werden dies geschieht ber Vererbung Objekte mssen Methoden anderer Klassen verwenden knnen dies geschieht ber Assoziationen Objekte mssen zur Bildung komplexerer Objekte einsetzbar sein dies geschieht ber Aggregationen Ist die Verbindung nur unter Einschrnkungen mglich, so mssen ihr eigene Attribute zugeordnet werden dies geschieht ber Abhngigkeiten W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 62 von xx
  • Folie 63
  • UML: Beispiel fr ein Klassen-Diagramm W. Scheuermann Universitt 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
  • Folie 64
  • UML: Methoden zum Finden von Objekten und Klassen Es gibt kein einheitliches Vorgehensmodell fr die Modellierung mit Objekten. Die Auswahl einer Modellierungsmethode ist eine projektspezifische Entscheidung und kann - abhngig von der Problemstellung - sehr unterschiedlich ausfallen. Fr Ingenieurprobleme hat sich eine Top-down Analyse analog der strukturierten Analyse bewhrt. Sie beginnt in der Regel mit einer Use Case-Modellierung W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 64 von xx Prozediagramm 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
  • Folie 65
  • UML: Methoden zum Finden von Objekten und Klassen CRC - (Class - Responsibility - Collaboration) Methode Hauptwortmethode: Hauptwrter ergeben Klassen Aber Achtung: Hauptwrter, die eher Werte haben (Lnge, 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 (Geschfts-)Prozesse (Ablufe im Modell) als Klassen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 65 von xx
  • Folie 66
  • UML: Paket-Diagramm Strukturierung eines Software-Systems in grere Einheiten als Klassen Vermittelt einen Grobberblick ber ein Software-System Wichtig fr Darstellung von Abhngigkeiten auf hherer Ebene W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 66 von xx
  • Folie 67
  • UML: Elemente eines Paket-Diagramms W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 67 von xx Paket Abhngigkeit: Paket A hngt vom Paket B ab
  • Folie 68
  • UML: Beispiel fr ein Paketdiagramm W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 68 von xx Freisetzung Transport Dosisberechnung
  • Folie 69
  • UML: Komponenten-Diagramm Eine Komponente ist ein unabhngiger, 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 untersttzt als Komponenten in Form von Quellcode Komponenten in Form von Binrcode Komponenten in Form von ausfhrbaren Code W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 69 von xx
  • Folie 70
  • UML: Elemente eines Komponenten-Diagramms W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 70 von xx Komponente Interface (Schnittstelle) Die Komponente A realisiert das Interface A Die Komponente A hngt vom Interface der Komponente B ab.
  • Folie 71
  • UML: Beispiel fr ein Komponenten-Diagramm W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 71 von xx ZDH- Service Windfeld- Berechnung
  • Folie 72
  • UML: Sequenz-Diagramm Darstellung von dynamischen Ablufen Kommunikation zwischen Objekten Geeignet: Wenn (viele) Botschaften zwischen wenigen Objekten ausgetauscht werden W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 72 von xx
  • Folie 73
  • UML: Darstellung eines Sequenz-Diagramms W. Scheuermann Universitt 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
  • Folie 74
  • UML: Kollaborations-Diagramm Dieselbe Information wie im Sequenz-Diagramm Darstellung von dynamischen Ablufen Kommunikation zwischen Objekten Geeignet: Wenn wenige Botschaften zwischen vielen Objekten ausgetauscht werden evtl. spter auch fr Debugging von Programmen W. Scheuermann Universitt Stuttgart - Ziel und Rahmenbedingungen - Feb-14Seite 74 von xx
  • Folie 75
  • UML: Darstellung eines Kollaborations-Diagramms W. Scheuermann Universitt 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