Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04.

Ähnliche Präsentationen


Präsentation zum Thema: "Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04."—  Präsentation transkript:

1 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 1 Hauptfachpraktikum "Simulation komplexer technischer Anlagen" WS 03/04 Prof. Dr. Fritz Schmidt Dr. Darko Sucic Die vorliegende Version dieses Praktikums wurde mit Technologien, die im Rahmen des Projektes MuSofT des BMFT und der Projekte 100online und self-study der Universität Stuttgart entwickelt werden konnten, multimedial gestaltet und evaluiert. Wir danken für die vielfältigen Anregungen und die großzügige Unterstützung

2 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 2 Ansprechpartner Vorlesung:Praktikum und Übungen: Prof. Dr. F. SchmidtDarko Sucic Telefon: 0711/ Telefon: 0711/ Anschrift: Institut für Kernenergetik und Energiesysteme Abteilung Wissensverarbeitung und Numerik (WN) Universität Stuttgart Pfaffenwaldring 31 D Stuttgart Homepage der Abteilung WN am IKE

3 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 3 Inhalt Praktikum Entwicklung eines komponentenbasierten Systems Versuch 1. Was wollen wir tun - das Pflichtenheft Versuch 2. Wie wollen wir das tun - UML + Projekthandbuch Versuch 3. Mit was wollen wir das tun 1 - Modellierung mit Omondo Versuch 4. Mit was wollen wir das tun 2 - Entwicklungsumgebung Eclipse Versuch 5. Mit was wollen wir das tun 3 - Das Team, seine Produkte und deren Integration mit CVS Versuch 6. Testumgebung + Testplanung Versuch 7. Implementierung Versuch 8. Integration Versuch 9. Der Personal Softwareprozess Versuch 10. Abschlussdiskussion - was würden wir das nächste mal besser machen Simulationsplattform, Komponenten und Java

4 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 4 Praktikum: Zeitlicher Ablauf Sitzung 1-2 Konzeption: Definition der Aufgabe (Gebäudesimulation) und des Vorgehens –Einfluss der Modellierung - Anlegen des Pflichtenheftes –Tailoring des Vorgehensmodelles - Anlegen eines Projekthandbuches Sitzung 3-6 Entwurf: Detaillierung des Vorgehens –Einrichten der Projektumgebung –Erstellung der Spezifikation für eine Berechnungskomponente –Definition der Rollen –Definition der Aufgabenerfüllung Sitzung 7-8 Implementierung: Entwicklung einer Berechnungskomponente –Implementierung des Entwurfes –Integration in ein lauffähiges Programm Sitzung 9-10 Einführung und Betrieb: –Validierung des Programmes –Optimierung des Entwicklungsprozesses zwecks Qualitätsverbesserung

5 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 5 Praktikum im Unified Prozess

6 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 6 Das sollten Sie im Praktikum lernen Techniken zum Bau virtueller Anlagen, die wir erproben wollen –Das V-Modell als Basis des Qualitätsmanagements –Der Rational Unified Process als Vorgehensmodell für die Softwareentwicklung –Die Unified Modeling Language als Basis der Modellierung –Testgetriebene Entwicklung von Komponenten als Basis der Implementierung –Refactoring als Basis der Verbesserung einer Implementierung –Produktmodelle als Basis der Systembeschreibung –Der Personal Software Prozess als Basis der Verbesserung der eigenen Software

7 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 7 Videos im Praktikum Wir ergänzen das Praktikum durch eine Reihe von Videos, die in die Aufgabenstellung und die zur Lösung vorgeschlagenen Wege und Werkzeuge erläutern. Sie sind zum Teil von Partnern im Projekt MuSofT entwickelt worden (CVS, UP Tutor und Lehrbuch) oder Firmenpräsentationen entnommen (RUP). Eigene Videos haben wir zusammen mit der Hochschule der Medien Stuttgart (HdM, Prof. F. Toenniessen entwickelt Sie finden eine multimediale Anleitung zur Bedienung dieser Videos unter Anleitung Die zum Abspielen nötigen Plugins stehen unter Plugins zur Verfügung

8 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 8 Versuch 1. Was wollen wir tun - das Pflichtenheft Einfluss der Modellierung am Beispiel der Gebäudesimulation Ziel: Erstellung des Pflichtenheftes für das Praktikum Schritt 1 Das Problem - Einführung mit Video Anforderungsdefinition Schritt 2 Beschreibung der Aufgabe (Lastenheft) Schritt 3 Erstellung eines Pflichtenheftes Vertiefende Informationen Lernmodul KS-V1 Modelle

9 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 9 Modellierungstufen physikalisches Modell mathematisches Modell numerisches Modell Simulationsmodell Quantifizieren Diskretisieren Implementieren Reale Komponente Verhalten Parameter Verhalten Parameter Verhalten Parameter Verhalten M O D E L L I E R U N G

10 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 10 Physikalisches Modell: Energiebilanz-Raum Raum Außenwand: Raum (Konvektion und Strahlung): Raum (Latent):

11 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 11 Mathematische Modelle für die Energiebilanz Statische Verfahren (steady state) –Lastberechnungen Erweiterte statische Verfahren (enhanced stady state) –DIN V –DIN EN 832 Dynamische Verfahren (non-stationary, transient) –Differenzen und Finite-Elemente-Verfahren –Response-Faktoren (Gewichtsfaktoren) –Beuken-Modell –Regeltechnisches-Ersatzmodell

12 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 12 Merkmale der statischen Verfahren Statische Verfahren (Lastberechnungen) –Basierend auf Daten eines Gradtages –Keine Berücksichtigung der Wärmespeicherfähigkeit des Gebäudes Erweiterte statische Verfahren (DIN V , DIN EN 832) –Basierend auf Monatsmittelwerten –Berücksichtigung der passiven Energielasten und Wärmespeicherfähigkeit des Gebäude durch sog. monatlichen Ausnützungsgrad

13 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 13 Merkmale der dynamischen Verfahren Differenzen und Finite-Elemente Verfahren –Diskretisierung des Differentialgleichungsystems –Eindimensionaler Wärmestrom Response-Faktoren (Gewichtsfaktoren) –Bestimmung des Übertragungsverhaltens des Raumes –Kopplung der Übertragungsfunktionen mit Eingangsgrößen –Zeitinvariantes Verhalten –Superpositionsprinzip Beuken-Modell –Elektrisches Analogiemodell (Formale Übereinstimmung der Differentialgleichungen der Wärmeleitung und Potentialgleichung für idealisiertes Kabel) Regeltechnisches Ersatzmodell

14 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 14 Entwicklung des Problemverständnisses Identifikation der wichtigsten Parameter –Parametervariation bei einem Verfahren Vergleich verschiedener zeitlicher Auflösungen –Grenzen der Modellierung bei vorgegebenen Parametern

15 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 15 Beispielgebäude

16 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 16 Beispielgebäude-Datenblatt

17 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 17 Physikalisches Modell Zonenweise stationäre Energiebilanz bei vorgegebener Soll- Innentemperatur

18 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 18 Mathematisches Modell Transmissionsverluste: Lüftungsverluste: Interne Wärmegewinne: Mittlere interne Wärmegewinne auf der Basis eines durchschnittlichen 2,7- Personenhaushaltes bezogen auf die Wohnraumfläche Statisches Verfahren auf monatlicher Basis mit folgenden Gleichungen: Solare Wärmegewinne:

19 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 19 Numerisches Modell Transmissionsverluste: Lüftungsverluste: Interne Wärmegewinne: Solare Gewinne:, dann sind die obigen Gleichungen für jeden Monat zu lösen und die monatlichen Werte von aufzusummieren

20 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 20 Lastenheft für Praktikum 2003/04 Erweiterung eines Programmes zur Berechnung des Verlaufs des Wärmebedarfs über ein Jahr auf der Basis einer monatlichen stationären Energiebilanz bei einer konstanten Soll-Innentemperatur. Berücksichtigt werden sollen Transmission, Lüftung, solare und interne Wärmegewinne. Soll-Innentemperatur, Lüftungsrate und Nutzungsgrad sollen variabel sein. Für jeden Zeitschritt soll der monatliche Wärmebedarf, sowie dessen Anteile an Transmission, Lüftung und interner Wärmegewinne berechnet und visualisiert werden. Für den gesamten Berechnungszeitraum sollen die Summenwerte auf dem Bildschirm ausgegeben werden. In diesem Praktikum soll eine zweite, beheizte Zone eingeführt werden

21 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 21 Praktikumsaufgaben - Block 1 Erstellen Sie das Pflichtenheft für die folgenden Tage Verwenden Sie folgende Vorlagen –Ablaufmodell Praktikum in ProModUP –Vorlage Pflichtenheft Praktikum Pflichtenheft Text: Wie setzt man Use Cases einWie setzt man Use Cases ein

22 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 22 Versuch 2 Wie wollen wir das tun - UML + Projekthandbuch Vorgehensmodelle Ziel: Erstellung des Projekthandbuches für das Praktikum Schritt 1 Das Problem - Einführung in das V-Modell Schritt 2 Video zur Einführung in den RUP Schritt 3 Modellierung des Praktikums mit ProModUP Schritt 4 Anlegen eines Projekthandbuch Schritt 5 Beschreibung der Aufgabe für dieses Praktikum in Projekthandbuch Vertiefende Informationen Vorlesung KS V3 Prozesmodelle MuSofT LE 3.1 LM 4 Das V-Modell im Überblick LE 3.1 LM 5 V-Modell Anwendung LE 3.1 LM 7 V-Modell und Unifid Process LE 3.3 der Uni Dortmund

23 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 23 Warum brauchen wir Vorgehensmodelle ? Entwicklungsprojekte auch im Softwareengineering streben in der Regel folgende Ziele an: Erfüllen der vom Auftraggeber definierten Anforderungen Einhalten des vorgegebenen Zeitrahmens Beschränkung auf das zur Verfügung stehende Budget Erreichen der benötigten Qualität Um diese Ziele erreichen zu können, bedarf es einer strukturierten Vorgehensweise. Ist diese standardisiert, so lassen sich der vom Projekt zu erbringende Aufwand zur Entwicklung des Vorgehensmodells senken, die Qualität des Modells erhöhen und das Vertrauen in seine Anwendung bei Auftraggebern und Auftragnehmern vertiefen. Dies war auch Motivation für die Entwicklung des V-Modelles.

24 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 24 Was ist das V-Modell ? -1 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)

25 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 25 Was ist das V-Modell ? -2 Zu jeder Aktivität existiert eine Aktivitätenbeschreibung 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.

26 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 26 Elemente des V-Modell 97 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 und akzeptiert annehmen Beschreibungsmuster stehen als Templates für Produkte und Listen der Aktivitäten zur Verfügung

27 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 27 Submodelle des 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. Das V-Modell wurde 1992 als Rahmenregelung für alle Bundesbehörden empfohlen. Aufgrund von Anregungen der V-Modell-Anwender wurde es in 1996/97 so überarbeitet, dass auch objektorientierte Vorgehensweisen modelliert werden können.

28 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 28 Zusammenspiel der Submodelle

29 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 29 Submodell Systemerstellung

30 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 30 Hauptaktivitäten des Subsystems SE System-Anforderungsanalyse (SE 1) Beschreibung der Anforderungen an das zu erstellende System und seine technische und organisatorische Umgebung; Durchführung einer Bedrohungs- und Risikoanalyse; Erarbeiten eines fachlichen Modells für Funktionen/Daten/ Objekte. System-Entwurf (SE 2) Zerlegung des Systems in Segmente sowie SW- (Software-) und HW- (Hardware-) Einheiten. SW-/HW Anforderungsanalyse (SE 3) Die technischen Anforderungen an die SW- und ggf. HW-Einheiten werden präzisiert. Von hier ab spaltet sich der weitere Fortgang in die SW- Entwicklung und ggf. in die HW-Entwicklung SE4-SW bis SE7-SW SE4- HW bis SE9-HW

31 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 31 Hauptaktivitäten des Subsystems SE Software-Entwicklung (SE4-SW bis SE7-SW) Die Software-Entwicklung hat nach einem dem Projekt adäquaten Prozessmodell zu erfolgen. System-Integration (SE 8) Integration der verschiedenen Software- und Hardwareeinheiten zu einem Segment und Integration der Segmente (falls vorhanden) zum System. Überleitung in die Nutzung (SE 9) Beschreibung aller Tätigkeiten, die notwendig sind, um ein fertiggestelltes System an der vorgesehenen Einsatzstelle zu installieren und in Betrieb zu nehmen.

32 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 32 Kernaktivitäten und -Produkte des Submodells Softwareentwicklung Aktivität Systemanforderungsanalyse Systementwurf Softwareanforderungsanalyse Softwaregrobentwurf Softwarefeinentwurf Softwareintegration Softwareimplementierung Softwareintegration Systemintegration Nutzerfreigabe Produkt Anwenderforderungen Systemarchitektur Technische Anforderungen Softwarearchitektur Softwareentwurf Module und Datenbanken Softwareeinheiten System Installiertes System

33 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 33 Beispiel: Wasserfallmodell als einfaches Phasenmodell Voraussetzungen: –Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) –Bekannte Technologien und Verfahren Analyse Design Kodierung Test Produkte: Schwerpunkt im Praktikum Spezifikation - Tag 1 Entwurf - Tag 2 Programm - Tag 3 und 4 Abnahmebericht - Tag 5 Aktivitäten

34 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 34 Teil-Submodell Softwareentwicklung V-Modell der Software-Entwicklung (Thaller: ISO 9001) zeigt die Verbindung von Prozessmodell und Qualitätssicherung

35 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 35 Rational Unified Process (RUP) - Definitionen 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.

36 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 36 Phasen und ihre 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 EntwurfEinführung Konzeption Realisierung Iterationen umfassen jeweils alle Workflows einer Phase

37 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 37 RUP in der Praxis Zum RUP existiert eine online Version. Mit dieser Version können Sie: –direkt aus einem Projekt auf den RUP zugreifen und sich Hilfestellung für die aktuelle Arbeit geben lassen –Das aufgezeigte Vorgehen in der Praxis erproben –weitere Details für ein optimales Tailoring auf Ihr Projekt hin erarbeiten. Starten sie den RUP hier.RUP Im Rahmen des Projektes MuSofT wurde ein Lehrbuch für den UP entwickelt und ein einfacher Modellierer. Beide stehen Ihnen im Rahmen des Praktikums zur VerfügungLehrbuchModellierer Zum Arbeiten mit dem RUP gibt es ein Video. In ihm werden alle wichtigen Arbeitsschritte erläutert. Starten Sie die RUP - Demo hier.RUP - Demo Wir wünschen viel Erfolg

38 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 38 Submodell QualitätssicherungQualitätssicherung QS-Initialisierung Prüfung vorbereiten Produkt prüfen Prozessprüfung von Aktivitäten QS-Berichtswesen Durchführungs- entscheidung Fertigprodukt prüfen

39 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 39 Hauptaktivitäten des Subsystems QS -1 QS-Initialisierung (QS 1) Die QS-Initialisierung legt den organisatorischen und abwicklungstechnischen Rahmen im QS-Plan und in Prüfplänen fest. Prüfungsvorbereitung (QS 2) Zur Prüfungsvorbereitung gehören die Erstellung von Prüfspezifikation und -prozedur und die Vervollständigung des Prüfplans sowie Anforderungen an die Prüfumgebung. Die Prüfkriterien müssen so festgelegt werden, dass der Erfolg oder Misserfolg einer Prüfung eindeutig und nachvollziehbar entschieden werden kann.(Es kann nicht Qualität sondern nur die Erfüllung von Qualitätskriterien geprüft werden) Prozessprüfung von Aktivitäten (QS 3) Bei der Prozessprüfung (nach DIN 55350) wird festgestellt, ob vorgegebene Vorgehensweisen bei der Durchführung bestimmter Aktivitäten eingehalten werden.

40 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 40 Hauptaktivitäten des Subsystems QS -2 Produktprüfung (QS 4) Die Produktprüfung erfolgt in zwei Stufen: Prüfung der formalen Kriterien und inhaltliche Prüfung des Produktes. Für die Prüfungen sind die Prüfspezikationen zu verwenden. Das Ergebnis wird in einem Prüfprotokoll festgehalten. QS-Berichtswesen (QS 5) Hier sind in regelmäßigen Abständen die Prüfprotokolle nach vorgegebenen Kriterien auszuwerten und die Ergebnisse dem Projektmanagement vorzulegen.

41 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 41 Submodell Projektmanagement Dies sind Aufgaben der Praktikumsleiter Projekt initialisieren Hauptaktivität initialisieren Hauptaktivität begleiten Hauptaktivität abschließen Projekt abschließen

42 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 42 Hauptaktivitäten des Subsystems PM Projekt initialisieren: Regelt den organisatorischen Rahmen für das gesamte Projekt im Projektplan und Projekthandbuch. Legt Modalitäten für die projektinterne Zusammenarbeit und die Schnittstelle zum Auftraggeber fest. Erfordert Anpassung des Vorgehensmodells (Tailoring). Projekt begleiten mit den Phasen Initialisieren, Begleiten und Abschließen der einzelnen Aktivitäten im Projekt. Projekt abschließen: Aufbereitung der Ergebnisse, Soll-Ist-Vergleich mit Verbesserungsvorschlägen.

43 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 43 Submodell Konfigurationsmanagement Hierzu kurze Einführung in CVS KM-Initialisierung Konfigurations- verwaltung Änderungs- management KM-BerichtswesenDatensicherung

44 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 44 Hauptaktivitäten des Subsystems KM KM-Initialisierung (KM 1) Die KM-Initialisierung regelt den organisatorischen und abwicklungstechnischen Rahmen im KM-Plan. Des weiteren sind die Einsatzmittel (Produktbibliothek, Werkzeuge) bereitzustellen. Produkt- und Konfigurationsverwaltung (KM 2) Die Produkt- und Konfigurationsverwaltung umfasst das Verwalten von Produkten, Konfigurationen und Rechten. Änderungsmanagement (KM 3) Über das Änderungsmanagement werden eingehende Fehlermeldungen, Problemmeldungen, Verbesserungsvorschläge usw. erfasst und über die im KM- Plan festgeschriebenen Änderungsprozeduren einer kontrollierten Bearbeitung zugeführt. KM-Dienste (KM 4) Unter KM-Dienste werden allgemeine Serviceleistungen zusammengefasst. Zwei Beispiele sind angegeben.

45 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 45 Projekt Studienarbeit Es wird die Anwendung des V-Modelles für die Erstellung von Seminar-, Studien- und Diplomarbeiten erläutert. Prozessmodell ist das Phasenmodell in seiner Ausprägung Wasserfallmodell. Ziel der Anwendung ist es studentische Arbeiten transparenter zu machen und das Risiko ihres Scheiterns zu verringern. Durch Anwendung eines Vorgehensmodells auf ein studentisches Projekt sollen gleichzeitig Aufwand und Chancen modernen Qualitätsmanagements vermittelt werden. Einen ersten Satz von Ablaufdiagrammen und Dokumenten findet man unter folgendem Link: management/index.html Dies ist die Basis für das Verständnis der entsprechenden Übungsumgebung

46 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 46 Projekt Studienarbeit im V Modell Link: Projekt Studienarbeit Projekt Studienarbeit

47 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 47 Zum Nachlesen und zur aktuellen Information –Kurzfassung VorgehensmodellKurzfassung Vorgehensmodell –V-Modell HandbuchV-Modell Handbuch –Musterprojekt kleine VorhabenMusterprojekt kleine Vorhaben –Musterprojekt große VorhabenMusterprojekt große Vorhaben –Vorlage Projekthandbuch PraktikumProjekthandbuch Praktikum –Lehrbuch (Unified Process der Uni Dortmund)Lehrbuch (Unified Process der Uni Dortmund)

48 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 48 Das V-Modell in der Praxis Durchführung von Studien- und Diplomarbeiten am IKE-WN auf der Basis von AIDA des IAS Weitere wichtige Adressen V-Modell Entwickler V - Modell Browser V-Modell Verein Ansstand V-Modell Guide (elektronischer Führer)

49 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 49 Praktikumsaufgaben - Block 2 Erstellen Sie das Projekthandbuch und das Review Protokoll für die folgenden Tage Verwenden Sie folgende Vorlagen –Ablaufmodell Praktikum in ProModUP –Vorlage Review Protokoll Praktikum Review Protokoll –Vorlage Projekthandbuch PraktikumProjekthandbuch

50 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 50 Versuch 3. Mit was wollen wir das tun 1 - Modellierung mit Omondo Modellierung mit der Unified Modelling Language Ziel: Erstellung des UML Modelles für das Praktikum Schritt 1 Das Problem - Einführung mit Video Modellieren mit OMONDO Schritt 2 Analyse des UML Modelles vom Vorjahr Schritt 3 Erweiterung des Modelles um Aufgaben dieses Praktikums Vertiefende Informationen Vorlesung KS V4 Modellierung mit der UML

51 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 51 Ergebnis der Analyse Statisches, monatliches Berechnungsverfahren Berechnung Wärmebilanz für Standardzone vorhanden Erweiterung des Frameworks um die Berechnung ???

52 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 52 UML - Unified Modelling Language UML stellt zur Verfügung: –ein Meta-Modell (grundlegende Modellierungskonzepte, Modellelemente und ihre Semantik) –eine graphische Notation zur Visualisierung des Meta-Modells –Richtlinien (Namenskonventionen, Anordnung von Symbolen usw.) UML ist keine Methode, weil sie kein Vorgehensmodell definiert UML ist für den gesamten Software-Lebenszyklus entwickelt worden

53 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 53 UML-Kurzbeschreibung Ein auf der Unified Modeling Language basierender Softwareentwicklungsprozess ermöglicht eine durchgängige objektorientierte Entwicklung. Aufbauend auf den Anforderungsdokumenten werden so genannte Use-Cases entwickelt. Sie dienen der Kommunikation mit dem Kunden und dem Entwicklungsteam. Nachdem die Anforderungen in Use- Cases umgesetzt wurden, werden diese oft verfeinert. Hierbei kommen Interaktions- und Aktivitätsdiagramme zum Einsatz. Diese Diagramme können gemeinsam mit den Anforderungsdokumenten in Klassendiagramme umgesetzt werden. Das entstandene System enthält zunächst nur die fachliche Struktur der Software. Daher m¨ussen diese Diagramme in der Entwurfsphase um technische Klassen ergänzt werden. Diese Klassen bilden das Gerüst der Implementierung. Die Funktionsweise der eingefügten Klassen ist nur durch implizite bzw. informelle Informationen beschrieben.Aus diesen Informationen müssen die noch fehlenden Attribute und Operationen der Klassen identfiziert und zugeordnet werden. Anschließend wird die so gewonnene objektorientierte Struktur in der gewählten Programmiersprache realisiert und geprüft.

54 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 54 Diagrammtypen der UML Die am häufigsten verwendeten Diagramme –Use Case-Diagramm –Klassendiagramm –Paketdiagramm –Komponenten-Diagramm Weitere Beispiele für Diagramme –Interaktionsdiagramm (Sequenzdiagramm, Kollaborationsdiagramm) –Zustandsdiagramm –Deployment-Diagramm Die von Omondo unterstützten Diagramme sind rot markiert

55 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 55 Klassendiagramm 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 (abstract, interface) –Kardinalitäten der Beziehungen –Navigationsfähigkeit –usw.

56 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 56 Elemente eines Klassendiagramms Vererbung: Klasse A erbt von der Klasse B Klasse Abhängigkeit: Klasse A hängt von der Klasse B in irgendeiner Art und Weise ab (z.B. A nutzt Attribute von B Aggregation: Klasse A beinhaltet die Klasse B Assoziation: Klassen A und B stehen in einer Beziehung zu einander Achtung: Die Implementierung dieser Elemente hängt vom Programmiermodell der verwendeten Programmiersprache ab

57 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 57 Das RENSim Framework

58 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 58 Vorstellung des UML Werkzeuges Omondo Omondo ist ein Case Tool der Firma Omondo Omondo unterstüzt: –Use-Case Diagramme –Klassendiagramme –Sequenzdiagramme Es ist Teil vom Eclipse Modelling Framework (EMF) und steht als Plug-in zur Verfügung Eine aktuelle Einführung findet man auf unterThe use of EMF by Eclipse (more...)www.omondo.com Diese Einführung liegt dieser und folgender Einheit zur Grunde.

59 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 59 Modellierung mit Omondo

60 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 60 UML 2.0 Verabschiedung der Version 2.0 im Sommer 2003 Wichtigste Neuerungen –UML 2.0 Modelle sind ausführbar –Beschreibung komplexer Architekturen (Subsysteme) möglich –Unterstützung iterativer Strukturen –Modellierung von Realtime und embedded Systemen möglich –Bessere Unterstützung komponentenbasierter Entwicklung

61 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 61 Weitere Informationen und Werkzeuge zu UML Offizielle UML Suite der OMG Link Sammlung zum Thema UML Werkzeug Vergleich Standardisierungspartner

62 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 62 Praktikumsaufgaben - Block 3 Arbeiten Sie sich in Omondo ein Analysieren Sie das RENARCH framework Tragen Sie das Ergebnis Ihrer Analyse in das Projekthandbuch ein

63 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 63 Versuch 4. Mit was wollen wir das tun 2 - Entwicklungsumgebung Eclipse Einrichtung einer Entwicklungsumgebung für das Praktikum Ziel: Einführung in die werkzeuggestützte Entwicklung Schritt 1 Das Problem - Einführung mit Video Arbeiten mit Eclipse Einführung mit Video Refactoring mit Eclipse Schritt 2 Erforschen der eclipse Umgebung Schritt 3 Reengineering des RENARCH Famework Vertiefende Informationen Vorlesung KS V3 Externe Programming

64 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 64 Brief History of Eclipse 1999 April- Work begins on Eclipse inside OTI/IBM 2000 June - Eclipse Tech Preview ships 2001 June- Eclipse 0.9 ships October- Eclipse 1.0 ships November- IBM donates Eclipse source base - eclipse.org board announced - openshttp://www.eclipse.org/ 2002 June- Eclipse 2.0 ships September- Eclipse ships November- Eclipse ships 2003 March- Eclipse 2.1 ships

65 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 65 Vorstellung der Entwicklungsumgebung Eclipse Universelle Plattform zur Integration von Entwicklungswerkzeugen mit einer offenen, erweiterbaren Architektur basierend auf Plug-ins Plug-in implementiert Funktionalität für einen oder mehreren Erweiterungspunkte definiert innerhalb der Plattform oder eines anderen Plug-ins Laufzeitumgebung der Plattform entdeckt installierte Plug-ins und lädt diese beim Start Plug-ins sind gruppiert und installiert als features Eclipse verfügt über eine Windows Oberfläche auf Basis der SWT Library (statt der sonst in Java üblichen Swing lib) Eclipse wurde ursprünglich von IBM entwickelt, ist jetzt aber frei verfügbar. Mehr zum Eclipse Projekt findet man unter

66 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 66 Platform Runtime Workspace Help Team Workbench JFace SWT Eclipse Project Java Development Tools (JDT) Their Tool Your Tool Another Tool Eclipse Overview Plug-in Development Environment (PDE) Eclipse Platform Debug

67 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 67 What is Eclipse? Java VM Standard Java2 Virtual Machine Platform Eclipse Platform Java development tools JDTPDE Plug-in development environment Eclipse is a universal platform for integrating development tools Open, extensible architecture based on plug-ins

68 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 68 Eclipse Plug-in Architecture Plug-in A –Declares extension point P –Declares interface I to go with P Plug-in B –Implements interface I with its own class C –Contributes class C to extension point P Plug-in A instantiates C and calls its I methods plug-in A plug-in B class C interface I extension point P extension Typical arrangement contributes creates, calls implements

69 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 69 Eclipse Platform Eclipse Platform is the common base Consists of several key components Platform Runtime Eclipse Platform Workspace Workbench SWT JFace TeamHelp Debug Ant Core UI

70 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 70 Workspace Component Tools operate on files in users workspace Projects map to directories in file system {Files, Folders, Projects} termed resources Workspace holds 1 or more top-level projects Tools read, create, modify, and delete resources in workspace Plug-ins access via workspace and resource APIs Tree of folders and files

71 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 71 Workbench Component SWT – generic low-level graphics and widget set JFace – UI frameworks for common UI tasks Workbench – UI personality of Eclipse Platform Workbench SWT JFace

72 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 72 SWT SWT = Standard Widget Toolkit Generic graphics and GUI widget set –buttons, lists, text, menus, trees, styled text... Simple Small Fast OS-independent API Uses native widgets where available Emulates widgets where unavailable

73 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 73 JFace JFace is set of UI frameworks for common UI tasks Designed to be used in conjunction with SWT Classes for handling common UI tasks API and implementation are window-system independent

74 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 74 JFace APIs Image and font registries Dialog, preference, and wizard frameworks Structured viewers –Model-aware adapters for SWT tree, table, list widgets Text infrastructure –Document model for SWT styled text widget –Coloring, formatting, partitioning, completion Actions –Location-independent user commands –Contribute action to menu, tool bar, or button

75 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 75 Workbench Terminology Tool bar Perspective and Fast View bar Resource Navigator view Stacked views Properties view Tasks view Outline view Bookmarks view Menu bar Message area Editor Status area Text editor

76 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 76 Einige nützliche Plug-ins Lomboz – Wizards für J2EE Entwicklung Omondo – UML Klassendiagramme mit Round-trip Engineering Quantum DB – Datenbank Explorer und Query-Wizard Solar Eclipse – HTML/JSP/XML Editor Sysdeo Tomcat Launcher –Tomcat Wizards X-Men – XML Editor Junit – Junit support for Eclipse Diese und weitere Plug-ins können von heruntergeladen werden.

77 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 77 Kurse und Tips zum Arbeiten mit Java Auf dieser Seite finden Sie aktuelle Kursangebote zu Java Java tutorials von SUN Kleine Java Schule der FH Lübeck Guidelines, Patterns, and code for end-to-end Java applications

78 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 78 Spezifikation Basis-Berechnungsframework vorhanden Analyse des Frameworks mit Eclipse Erweiterung des Frameworks im Sinne des Pflichtenhefts

79 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 79 Praktikumsaufgaben - Block 4 Arbeiten Sie sich in Java ein Entwickeln Sie eine Klasse. Ergänzen Sie das Projekthandbuch

80 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 80 Versuch 5. Mit was wollen wir das tun 3 - Das Team, seine Produkte und deren Integration mit CVS Organisation des Arbeitens im Team Ziel: Verteilung der Aufgaben Schritt 1 Das Problem - Einführung mit Video CVS Schritt 2 Beschreibung der Projektstruktur in CVS Schritt 3 Verteilung der Rollen und Aufgaben im Praktikum Schritt 4 Festlegung der teaminternen Abnahmekriterien Schritt 5 Erweiterung des Projekthandbuches Vertiefende Informationen MuSofT LE 3.4 der Uni Siegen LE3.1 LM 2 Prozessqualität und Produktqualität

81 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 81 Das Team Allen Mitgliedern des Teams ist gemeinsam –Zugang zu den Produktenten des Systems –Der Entwicklungsprozess (z.B.RUP) –Das Verständnis wie Software entwickelt werden sollte –Die Modellierungswerkzeuge Designer / Developer Analyst Tester Database Administrator Performance Engineer Release Engineer Project Leader

82 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 82 Workers: das Team und seine Rollen im Projekt Workers sind Personen, die innerhalb eines Projektes eine bestimmte Aktivität durchführen, bzw. eine Rolle übernehmen Zentrale RollenFachwissen ArchitektTechnologie DomänenexperteAnwendungsbereiche ProjektleiterOrganisation QualitätsmanagerProjektziele Weitere RollenFachwissen Systemanalytiker Designer... Programmierer....

83 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 83 Besetzung der Rollen –Alle als projektnotwendig identifizierte Rollen müssen mit geeignet qualifiziertem Personal besetzt werden –Eine Person kann gleichzeitig mehrere Rollen übernehmen –Ggf. muss benötigtes Know-How durch Weiterbildung geschaffen oder zugekauft werden –Besetzung der Rollen kann Aufwände bis zu einem Faktor 10 variieren lassen oder Projekte sogar ganz zum Scheitern bringen –Daher einer der wichtigsten Aspekte eines erfolgreichen Projektes: Zuordnung von Mitarbeitern zum benötigten Anforderungsprofil

84 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 84 Projektmanagement im Praktikum Von den gemeinsamen Werkzeugen des Teams Zugang zu den Produkten des Systems Entwicklungsprozess (z.B.RUP) Verständnis wie Software entwickelt werden sollte Modellierungswerkzeuge Fehlt uns noch das gemeinsame Produktverwaltungssystem Die Produkte des Praktikums sind neben Pflichtenheft und Projekthandbuch die Softwareprodukte der einzelnen Arbeitsgruppen. Diese Produkte verwalten wir über das Concurrent Versioning System CVS

85 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 85 Versionsverwaltung Standardwerkzeug zum Konfigurationsmanagement im open source Bereich ist CVS (Concurrent Versioning System) Eine Einführung in CVS findet man unter Nachfolger von CVS soll Subversion werden. Subversion basiert auf WebDAV über HTTP und setzt auf Apache2 auf. Über ein Transaktionskonzept garantiert es die Konsistenz von Änderungen Weitere Informationen über die homepage der Uni Siegen

86 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 86 Praktikumsaufgaben - Block 5 Verteilen Sie Rollen für unser gemeinsames Projekt Entwickeln Sie das Projekthandbuch weiter Ergänzen Sie das Rensim Framework um eine Klasse zur Modellierung interner Gewinne Spezifizieren Sie weitere Klassen entsprechend Ihres Pflichtenheftes Beschäftigen Sie sich mit dem Konfigurationsmanagement System CVS

87 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 87 Versuch 6. Testumgebung + Testplanung Testgetriebene Entwicklung Ziel: Erstellung der Testumgebung und der Tests Schritt 1 Das Problem - Einführung mit Video JUnitTest Schritt 2 Erstellen der TestSuites für die Aufgabenpakete Schritt 3 Festlegung der Abnahme Tests Vertiefende Informationen VorlesungKS V5 Testgetriebene Entwicklung MuSoft LE 3.1 LM 1 Fehler und ihre Kosten LE 3.2 LM 10 Einzeltests LE 3.2 LM 11 Integrationstests LE 3.2 LM 12 Funktionstests LE 3.2 LM 13 Abnahmetests

88 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 88 Die Kosten von Software Die Kosten eines Software-Produkts setzen sich aus Herstellungskosten und Qualitätskosten zusammen. Alle Aufwendungen für das Erbringen der geforderten Leistung, das Erzeugen der Qualität, zählen zu den Herstellungskosten. Die Qualitätskosten umfassen alle (zusätzlichen) Anwendungen für das Verhüten, Erkennen, Lokalisieren und Beheben von Fehlern sowie die evtl. Folgekosten der Fehler, die erst im Betrieb auftreten. Software-Kosten Fehlerverhütungskosten Prüfkosten Fehlerkosten Herstellungskosten Qualitätskosten Folgekosten Garantiekosten Fehlerbehebungskosten

89 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 89 Maße für Softwarequalität Zahl der Probleme pro Nutzermonat Probleme werden gemeldet als Folge von –Eingabefehler –Verbesserungsvorschlägen –Fehlern im System Probleme sind –häufig durch andere Meldungen bekannt –wegen unbekanntem Systemzustand nicht reproduzierbar Problembehebung ist Aufgabe der Wartung –gutes Wartungsteam –fehlerarme und fehlertolerante Systeme Zahl der Fehler pro 1000 lines of code (kLOC) –Ziel der Einführung von Prozessmodellen und Tests 1 Fehler/kLOC

90 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 90 Fehlerbehebungskosten

91 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 91 Fehlerbehebungskosten

92 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 92 Prozessqualität und Produktqualität Grundannahmen Qualitätsziele werden während der Konzeptfindung vorgegeben. Der Entwicklungsprozess bestimmt Eigenschaften und Qualität des Produktes. Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden. Produktqualität Nachweis durch Prüfung Prozessqualität Anforderungen und/oder Erwartungen an das Produkt AnweisungenAusführung PROZESS Merkmale und Eigenschaften des Produktes

93 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 93 Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten Anforderungen –Tut die Software das, was sie tun soll? –Tut die Software das nicht, was sie nicht tun soll? Wie verhält sich Software in einer konkreten Umgebung –Betriebssystem –Rechnerausbau –Nutzermodell Wo sind die Grenzen der Software - Benchmarking –Zahl der Nutzer –Durchsatz –Compatibilität

94 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 94 Draft standards Drafting process Specs Durch Verification / Validation zur Produktqualität VERIFICATION VALIDATION Customer needs

95 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 95 Beispiel: Wasserfallmodell als einfaches Phasenmodell Voraussetzungen: –Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) –Bekannte Technologien und Verfahren Analyse Design Kodierung Test Produkte: Spezifikation Entwurf Programm Abnahmebericht Verifikation: Überprüfung der Produkte gegen Projekthandbuch und Anforderungen aus Vorphase Validierung: Überprüfung der Umsetzung der Anforderungen an Produkt Aktivitäten

96 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 96 Wieviel Fehler erwarten wir Antwort 1 das lehrt die Erfahrung mit einem konkreten Programmierteam Antwort 2 empirische Formel in Abhängigkeit der Lines of Code (LOC)

97 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 97 Fehlerreduktion durch Testen beim Wasserfallmodell Analyse Design Kodierung Test Kodierung Unit Test Integration Test System Test Zahlen nach Wheeler bezogen auf je 1000 lines of code 20 nach nach nach nach 7 20 nach 3 10 nach 1

98 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 98 Iterative-Inkrementelle Vorgehensmodelle (1) Anforderungen sind unvollständig wichtige Erkenntnisse werden erst im Laufe des Projektes gewonnen Analyse Design Kodierung Test Iteration 1 Iteration 2 Iteration N Annahmen: Verifikation und Validierung müssen nach jedem Inkrement erfolgen. Das erfordert häufiges Abarbeiten von Testsequenzen, wobei Änderungen im Testergebnis erklärt werden müssen (Regressionstests) Eine Unterstützung durch datenbankgestützte Tools wird notwendig

99 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 99 Teil-Submodell Softwareentwicklung V-Modell der Software-Entwicklung (Thaller: ISO 9001)

100 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 100 Phasen und ihre 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 EntwurfEinführung Konzeption Realisierung Iterationen umfassen jeweils alle Workflows einer Phase

101 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 101 Durch Softwareprüfung zu Produktqualität Software- Prüfung Software- Prüfung dynamische Prüfung dynamische Prüfung statische Prüfung statische Prüfung ohne Hilfe des Rechners ohne Hilfe des Rechners Test Leistungsmessung : mit Hilfe des Rechners mit Hilfe des Rechners Prüfung gegen Regeln Konsistenzprüfung Quantitative Untersuchung : Review :

102 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 102 Softwareprüfung und Fehlerbehebung Prüfung meint Erkennen von unerwartetem Verhalten stößt Prozess der Ursachenfindung an resultiert in Fehlerbehebung Fehlerbehebung führt zur Veränderung des Produktes kann unerwartetes Verhalten oder neue Fehler erzeugen Vergleich : Fehlerbehebung kann als Folge von Prüfungen geschehen, hat aber grundsätzlich andere Anforderungen und Ziele

103 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 103 Statische Testverfahren Systematische Verfahren zur gemeinsamen Durchsicht von Dokumenten (wie z.B. UML-Modelle, implementierte Klassen,...): Programminspektion: Stark formalisiertes Verfahren bei dem Dokument nach genau festgelegter Vorgehensweise durch Gutachterteam untersucht wird Review: Weniger formale manuelle Prüfmethode; weniger Aufwand als bei Programminspektion, ähnlicher Nutzen Walkthrough: Unstruktierte Vorgehensweise; Autor des Dokuments liest vor, Gutachter stellen spontan Fragen [Pair Programming: Programm wird von vornherein zu zweit erstellt]. Empirische Ergebnisse zur Programminspektion: Prüfaufwand liegt bei ca. 15 bis 20% des Erstellungsaufwandes 60 bis 70% der Fehler in einem Dokument können gefunden werden Nettonutzen: 20% Ersparnis bei Entwicklung, 30% bei Wartung

104 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 104 Vorgehensweise bei der Programminspektion Inspektionsteam besteht aus Moderator, Autor (passiv), Gutachter(n), Protokollführer und ggf. Vorleser (nicht dabei sind Vorgesetzte des Autors) Gutachter sind in aller Regel selbst (in anderen Projekten) Entwickler Inspektion überprüft, ob: –Dokument Spezifikation erfüllt (Implementierung konsistent zu Modell) –Für Dokumenterstellung vorgeschriebene Standards eingehalten wurden Inspektion hat nicht zum Ziel: –Zu untersuchen, wie entdeckte Fehler behoben werden können –Beurteilung der Fähigkeiten des Autors –[Lange Diskussion, ob ein entdeckter Fehler tatsächlich ein Fehler ist] Inspektionsergebnis: –Formalisiertes Inspektionsprotokoll mit Fehlerklassifizierung –Fehlerstatistiken zur Verbesserung des Entwicklungsprozesses Quelle A. Schürr

105 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 105 Ablauf einer Inspektion Auslösung der Inspektion durch Autor eines Dokumentes (z.B. durch Freigabe) Eingangsprüfung durch Moderator (bei vielen offensichtlichen Fehlern wird das Dokument sofort zurückgewiesen) Einführungssitzung, bei der Prüfling den Gutachtern vorgestellt wird Individualuntersuchung des Prüflings (Ausschnitt) durch Gutachter anhand ausgeteilter Referenzdokumente (mit Spezifikation, Standards,...) auf Inspektionssitzung werden Prüfergebnisse mitgeteilt und protokolliert sowie Prüfling gemeinsam untersucht Freigabe des Prüflings durch Moderator (oder Rückgabe zur Überarbeitung). Bemerkung: Von den gefundenen Fehlern entfallen auf die Individualprüfung ca. 80% und auf die gemeinsame Sitzung ca. 20% der Fehler.

106 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 106 Review und Walkthrough Review (abgeschwächte Form der Inspektion): Prozessverbesserung und Erstellung von Metriken steht nicht im Vordergrund Moderator gibt Prüfling nicht frei, sondern nur Empfehlung an Manager kein formaler Inspektionsplan mit wohldefinierten Inspektionsregeln Walkthrough: Autor des Prüflings liest ihn vor (ablauforientiert im Falle von Software) Gutachter versuchen beim Vorlesen ohne weitere Vorbereitung Fehler zu finden Autor entscheidet selbst über weitere Vorgehensweise Zielsetzungen: – Fehler/Probleme im Prüfling identifizieren – Ausbildung/Einarbeitung von Mitarbeitern

107 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 107 Dynamische Testverfahren Die zu betrachtende Komponente (Operation, Klasse, Paket, Gesamt-system) wird mit konkreten Eingabewerten ausgeführt und ihr Verhalten wird dabei beobachtet. Im wesentlichen lassen sich dabei folgende Alternativen unterscheiden: Strukturtest (White Box-Test): Die interne Struktur der Komponente oder ihrer UML-Spezifikation wird zur Testplanung und -überwachung herangezogen Funktionstest (Black Box-Test): Die interne Struktur der Komponente wird nicht betrachtet; getestet wird Ein-/Ausgabeverhalten gegen Spezifikation Regressionstest: Verhalten einer Komponentenversion wird mit Verhalten anderer Komponentenversionen verglichen. Ein Testwerkzeug speichert alle durchgeführten Testfälle und erlaubt die automatische Wiederholung auch beim Kunden

108 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 108 Strukturtest (White Box-Test) Zur Testplanung und -Überwachung wird die interne Struktur der Komponente oder ihrer UML-Spezifikation herangezogen. Folgende Varianten sind möglich kontrollflussbasiert: Ablaufverhalten von Operationen wird untersucht datenflussbasiert: Variablenzugriffe (setzen/lesen) stehen im Vordergrund zustandsbasiert: Zustände und Transitionen einer Klasse werden betrachtet.

109 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 109 Funktionstest Funktionstests prüfen die Implementierung gegen ihre Spezifikation und lassen die interne Programmstruktur unberücksichtigt: Komplementär zu bislang vorgestellten White-Box-Verfahren für Abnahmetest ohne Kenntnis des Quellcodes geeignet setzt (eigentlich) vollständig und widerspruchsfreie Spezifikation voraus repräsentative Eingabewerte/Szenarien müssen ausgewählt werden (man kann i.a. nicht alle Eingabekombinationen testen) –Sequenzdiagramme aus Anwendungsfällen (use cases) beschreiben wichtige Testfälle man braucht Fachwissen oder Orakel für Überprüfung der Korrektheit der Ausgaben –ausführbare Statecharts als Orakel verwenden

110 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 110 Regressions Test Was soll man nach Änderung in einem Programm testen –a) Tests für das gesamte Programm wiederholen? –b) Testfälle mit Fehlern wiederholen? Kleine Einheiten alle Tests Große Einheiten Fehlern Minimierung des Risikos durch Kapselung und Anpassung des Testumfanges an Schwere der Änderung

111 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 111 Wann hört man auf mit Testen Wenn Testbudget verbraucht bzw. Auslieferungszeitpunkt erreicht Die je Testfall (Zeiteinheit) gefundene Fehlerzahl sinkt unter gegebene Grenze n % absichtlich von einer Gruppe implantierter Fehler (seeded bugs) wurden von Testgruppe gefunden Aus jeder Klasse äquivalenter Eingabedaten wurde ein Repräsentant getestet. Testfälle decken alle (relevanten) Programmverzweigungen ab

112 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 112 Prüfung objektorientierter Programme im RUP. Tests in jeder Iteration Einzeltests Funktionstests Integrationstests Systemtests Abnahmetests Bei iterativ inkrementellem Vorgehen gilt: Jede Iteration muss komplett und korrekt abgeschlossen werden Regressionstests zur Absicherung der Korrektheit aller Komponenten bei fortlaufender Änderung Bei einer Iteration sollten pro Mitarbeiter nur etwa 100 bis 300 Zeilen geänderten Code zugelassen werden

113 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 113 Verfolgung von Anforderungen In objektorientierten Softwareentwicklungen kann Durchg¨angigkeit und Transparenz zwischen den Phasen Analyse, Entwurf und Implementierung erreicht werden. An den Phasen¨uberg¨angen werden Verfeinerungen, Erg¨anzungen und Pr¨azisierungen des Systems vorgenommen. Diese Durchg¨angigkeit bezieht aber leider nicht die Anforderungsdokumente mit ein. Schon nach der Umsetzung der Anforderungen in Use-Cases ist eine Verfolgbarkeit innerhalb der UML nicht mehr gew¨ahrleistet, da in den folgenden Diagrammen keine Bez¨uge zu den eigentlichen Anforderungen m¨oglich sind. Aus diesemGrund ist es in der Regel nicht m¨oglich, einen Zusammenhang zwischen objektorientierten Strukturbl¨ocken (z. B. Klassen und Operationen) und den Anforderungen, denen sie dienen, herzustellen. Man kann hier vomUse-Case-Bruch sprechen

114 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 114 Kleinste Testeinheit White Box Test Ziel Verifikation der korrekten Umsetzung von Anforderungen Einzeltests gibt es in einer Vielzahl von Ausprägungen. Dazu gehören Kontrollflussorientierte Tests wie –Anweisungsüberdeckungstest –Zweigüberdeckungstest –Pfadüberdeckungstest –Bedingungsüberdeckungstest Datenflussorientierter Test - insbesondere das Defs/Uses - Verfahren, bei dem jeder Variablenzugriff einer der Kategorien Wertzuweisung, Berechnung oder Prädikatenbildung zugeordnet wird, um daraus Bedingungen für die korrekte Verwendung und deren Test abzuleiten Unit Tests (Einzeltests)

115 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 115 Plan für Unit Tests Das JUnit Framework gibt einen Plan für Unit Tests vor. Es wird später weiter besprochen und mit Referenzen belegt

116 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 116 Incremental Testing Übergang von Unit Test zu Integrations Test Inkrementelle Erweiterung eines Systems um neue Klassen, Module oder Komponenten, wobei nach jeder Erweiterung die Testsuite durchlaufen wird Verfahren sehr aufwendig, erleichtert aber Fehlerlokation Verfahren erfordert Unterstützung durch Tools

117 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 117 Integrationsteststrategien Big Bang-Strategie: Alle Teile sofort integrieren und nur als Gesamtheit testen –Lokalisierung von Fehlern schwierig –Arbeitsteilung kaum möglich –Testen beginnt zu spät Top-down-Testverfahren: Zuerst A mit Dummies für B, C und D; dann B mit Dummies für E und F,... –Erstellung vernünftiger Dummies schwierig –Test der Basisschicht sehr spät Bottom-Up-Testverfahren: Zuerst E, F, G und H mit Testtreibern, die Einbindung in B, C und D simulieren; dann B, C und D mit Testtreiber... –Test des Gesamtverhaltens des Systems gegen Lastenheft erst am Ende –Designfehler und Effiziensprobleme werden oft erst spät entdeckt

118 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 118 Integrations Tests Überprüfung des fehlerfreien Zusammenwirkens von Softwarebausteinen Voraussetzung: Jeder Baustein wurde in Unit Test überprüft, so dass die Integrationstests der Überprüfung der Schnittstellen und des Zusammenwirkens über Schnittstellen dienen können White Box Test Integration der Softwarebausteine inkrementell: incremental testing Test vereinfacht sich, wenn –Teile einen möglichst großen inneren Zusammenhang haben (cohesion) –Zahl der Aufrufe und der auszutauschenden Parameter möglichst klein ist (low coupling)

119 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 119 Komponenten Tests Bei Komponenten sind nur Funktion und Schnittstelle, nicht aber deren Implementierung bekannt: funktionales Testverfahren Basis Lastenheft, Use Cases oder Benutzerhandbuch Testdaten durch Bildung von Äquivalenzklassen, d.h. Klassen mit gültigen bzw. ungültigen Ein- und Ausgabewerten Aus Äquivalenzklassen Ableitung von Grenzwerten: Grenzwertanalyse Aus Äquivalenzklassen Ableitung von speziellen Testdatensätzen, die fehlersensitive Testfälle repräsentieren: special value test Aus Äquivalenzklassen Ableitung von zufälligen Testdatensätzen: Zufallstests mittels Monte Carlo Verfahren

120 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 120 System Tests Test des Gesamtsystems (evtl. Prototyp) beim Auftragnehmer Basis des Abnahmetests einer Phase Übergang zwischen zwei Meilensteinen Basis Softwareanforderungen des Softwareentwicklungsvertrags Durchführung als Black Box Test, da Implementierung kaum mehr interessiert Ziel Validierung der Software Tips: siehe Abnahme Test

121 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 121 Abnahme Tests Systemtest mit Kunden Basis der Auslieferung der Software Übergang von Entwicklungs- in Wartungs-Phase Basis Softwareanforderungen des Softwareentwicklungsvertrags Durchführung als Black Box Test, da Implementierung nicht mehr interessiert Validierung der Software Tips: –Softwareanforderungen auf das Wesentliche konzentrieren, Abnahme Test sollte nicht länger als eine Tag (Projekte bis 1 ME) oder eine Woche (Projekte größer 1 ME) dauern –Systemtest sollte schon während Designphase geplant werden. Dann noch genügend Zeit, um Eckpunkte zu setzen und zu dokumentieren

122 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 122 Regeln für Tester - best practice 1 Prüfe das eigene Programm nie als Einziger Testen meint die Ausführung eines Programmes mit der Absicht Fehler zu finden Definiere das erwartete Ergebnis vor Planung und Durchführung eines Tests Dann ist Testen kreativ und intellektuell herausfordernd und ent-spricht einem Experiment, dessen Ausgang nicht vorhersagbar ist Der Abnahmetest sollte kein solches Experiment sein, sondern vorher geprobt werden Mit jedem erfolgreichen Test wird ein bisher unbekannter Fehler aufgedeckt Testfälle sollen sowohl gültige als auch ungültige und falsche Eingaben enthalten

123 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 123 Regeln für Tester - best practice 2 Testen kann nur die Anwesenheit von Fehlern, nie aber Fehlerfreiheit nachweisen Testen ist auch ein Versuch nicht verlangtes Verhalten zu finden Testen ist teuer. Testfälle sollten daher als wertvolle Investition, die wiederverwendet werden muss, betrachtet werden Testkultur ist wie die Kultur der Softwareentwicklung ein Prozess, der weiterentwickelt werden sollte

124 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 124 Plan für Abnahme Tests Funktionstests –Testfälle unter Berücksichtigung der Daten des Kunden entwickeln –Tests auf Zielrechner durchführen –Vorkehrungen für Wiederherstellung der Ausgangsumgebung treffen Strukturtests –Ergänzung der Funktionstests um nicht überdeckte Pfade bis vorgegebene Überdeckungsrate erreicht wird Regressionstests –Überprüfung der Auswirkung von Fehlerbeseitigung Sonstige Empfehlungen –Wiederanlaufen der Software nach Fehlerabbruch nachweisen –Soll die Software auch außerhalb der regulären Arbeitszeit einsatzbereit sein, dafür geeignete Tests beim Kunden vorsehen. –Erwartete Ergebnisse rechtzeitig vor Testbeginn dokumentieren –Kriterien für Akzeptanz möglichst eindeutig formulieren

125 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 125 Prüfung objektorientierter Programme -1 PRÜFUNG zerfällt in zwei Aufgaben Prüfung der Klassen Prüfung des Zusammenspiels der Klassen PRÜFUNG der Klassen umfasst Prüfung der Methoden der Klasse Prüfung der Benutzung von Methoden anderer Klassen Prüfung der geerbten Methoden. PRÜFUNG des Zusammenspiels der Klassen erfordert klare Strukturen zwischen Objekten Vermeidung von Programmiertricks, die Prinzipien der Modellierung missbrauchen.

126 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 126 Prüfung von Vererbung STRIKTE VERERBUNG Objekte der Unterklasse haben sämtliche Merkmale der Oberklasse Es müssen die zur Unterklasse neu hinzugefügten Operationen geprüft werden. NICHT-STRIKTE VERERBUNG Objekte der Unterklasse können Merkmale der Oberklasse nur teilweise übernehmen oder gar verändern. Es müssen die zur Unterklasse neu hinzugefügten und die in der Oberklasse veränderten Operationen überprüft werden. Achtung Oberklasse nicht mehr gekapselt. MEHRFACHVERERBUNG Objekte der Unterklasse können Merkmale aus mehreren Oberklassen übernehmen. Auswirkungen der Mehrfachvererbung oft schwer zu verfolgen. Empfehlung: Verwendung nur zur Vorgabe von Schnittstellen. Dann vererben Oberklassen nur Anforderungen (virtuelle Methoden) und Unterklassen erfüllen Anforderungen der Oberklasse.

127 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 127 Prüfung objektorientierter Programme -2 Vorgehen anhand eines Beispiels Architektur des Beispiels D D C C C1 F F B B A2 A1 E2 E1 E E A A x Y X erbt von Y x Y X benutzt Y x Y X erbt von Y x Y X benutzt Y

128 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 128 Prüfung objektorientierter Programme -3 PRÜFUNG - PRINZIP Betrachtet man die Verflechtung von benutzt-Relationen und Vererbung, so ist es sinnvoll, beim Prüfen zuerst die Klassen entlang der benutzt-Relation (top-down), dann die Klassen entlang dem Vererbungspfad zu betrachten. PRÜFUNG - SCHRITTE Reihenfolge: 1. Zuerst werden die von A benutzten Klassen A1und A2 geprüft. 2. Anschließend wird die Klasse A selbst geprüft. 3. Bevor die Klasse B geprüft werden kann, muss die von ihr benutzte Klasse F geprüft sein. Dazu werden a) zuerst die von deren Oberklasse E benutzten Klassen E1 und E2 b) und daraufhin die Klasse E geprüft. 4. Nachdem F geprüft ist, kann B geprüft werden. 5. Nun kann auch D geprüft werden. 6. Die von der Klasse C benutzte Klasse C1 wird als nächste geprüft. 7. Zum Schluss bleibt die Prüfung der Klasse C.

129 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 129 Testgetriebene Entwicklung In einer testgetriebenen Entwicklung schreibt der Anwender abwechselnd Tests und Anwendungscode, bis alle Tests fehlerfrei laufen. Grundsätzlich gilt: Alle Annahmen sind durch Tests zu verifizieren, nur was im Test steht ist zugesichertes Verhalten Tests tragen den Entwurf und seine Implementierung. Größere Umstellungen im Code werden mit geringerem Risiko möglich. Vertiefende Texte finden Sie unter Informationen zum Extreme programming findet man unter

130 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 130 JUnit Framework

131 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 131 Anwendung des JUnit Frameworks zum Systemtest Abnahmetests (LM13) Integrationstests (LM11) Funktionstests (LM12) Einzeltests (LM10)

132 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 132 Download und Installation von JUnit ist als Open Source Software unter der IBM Public License veröffentlicht. Die aktuelle Version (momentan JUnit 3.8) können Sie von SourceForge beziehen: Entsprechende Frameworks sind für nahezu alle gängigen Programmiersprachen frei erhältlich: Das JUnit-Framework kommt in einem JAR-Archiv namens junit.jar verpackt. Die vollständige Distribution besteht gegenwärtig aus einem ZIP-Archiv, in dem neben junit.jar auch dessen Quelltexte, dessen Tests, einige Beispiele, die JavaDoc-Dokumentation, die FAQ, ein Kochbuch und zwei sehr lesenswerte Artikel aus dem amerikanischen Java Report beiliegen. Machen Sie sich mal ruhig mit den Beigaben vertraut. Es lohnt sich. Zur Installation entpacken Sie bitte das ZIP-Archiv und übernehmen Sie junit.jar in Ihren CLASSPATH. Fertig!

133 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 133 Testing Frameworks im Internet Testing Framework (xUnit, unit testing) Kent Becks Orginal Test Framework Paper Xunit testing frameworks Bugzilla Automatisches Unit Testing Unit Teating mit Junit by F. Westphal Download Junit

134 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 134 Literatur D. A. Wheeler, Software Inspection: an industry best practice, Los Alamitos, 1966 G. J. Myers, The Art of Softwaretesting, New York, 1979 T. A. Thayer, Software Reliability, Amsterdam, 1978 G. E. Thaller, Software Test: Verifikation und Validation Heise, 2002

135 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 135 Praktikumsaufgaben - Block 6 Schätzen Sie ab, wieviel Fehler im Rensim Framework ohne Tests zu erwarten gewesen wären Analysieren Sie die in der Mängelliste monierten Fehler, die sich bei einem großen Projekt während der Abnahme eines Prototypen ergabenMängelliste Entwickeln Sie ein Qualitätskonzept für unser Projekt Entwicklung der Testklassen für Unittests Ihrer Software Machen Sie einen Vorschlag für einen Abnahmetest

136 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 136 Versuch 7. Implementierung Implementierung der Einzelaufgaben durch die jeweilige Gruppe Ziel: Erweiterung einzelner Klassen des RENARCH Frameworks unter Beibehaltung des allgemeinen Verhaltens beim Testen Schritt 1 Praktizieren einer testgetriebener Entwicklung Schritt 2 Dokumentation der Ergebnisse Vertiefende Informationen VorlesungKS V5 Testgetriebene Entwicklung MuSoft LE 3.2 LM 14 Risikomanagement

137 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 137 Best Practice in der Softwarentwicklung Verwalte Anforderungen (elektronisches Projekthandbuch) Entwickle iterativ (RUP) Nutze Komponenten (Java beans) Unterstütze Entwicklung visuell (Eclipse mit Omondo) Überprüfe Qualität in allen Phasen (Test suite) Verfolge Änderungen durch Dokumentation (CVS) Weitere Infos im Software Programm Manager Network Informationen zum Extreme programming findet man unter

138 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 138 Praktikumsaufgaben - Block 7 Implementierung der Entwürfe Durchführung der Tests Ändern der Methode

139 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 139 Versuch 8. Integration Erstellung der neuen Version des RENARCH applets Ziel: Bereitstellung der Artefakte für das Praktikum im WS 04/05 Schritt 1 Integration der Beiträge der einzelnen Gruppen Schritt 2 Test des Gesamtsystems Schritt 3Abnahme der Artefakte Schritt 4Diskussion der Ergebnisse mit dem Auftraggeber Vertiefende Informationen Excel Programm zur Berechnung des Energiebedarfes von Wohngebäuden (von D. Wagner)

140 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 140 Praktikumsaufgaben - Block 8 Integrieren Sie Ihre Klassen in das vorgegebene Framework unter Verwendung von CVS Erstellung einer neuen Version des Simulationsprogrammes Testen Sie das neue Programm durch einen geeigneten Abnahmetest Darstellung und Interpretation der Ergebnisse Durchführung des Abnahmetests

141 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 141 Versuch 9. Der Personal Softwareprozess Wie kann man den Softwarentwicklungsprozess verbessern Ziel: Tips zur iterativ inkrementellen Weiterentwicklung zum Software Ingenieur Schritt 1 Einführung in das Capability Maturity Model (CMM) Schritt 2 Einführung in den Personal Software Process Schritt 3 Einführung in das Test Maturity Model Schritt 4 Entwicklung von Vorschlägen für die Verbesserung der eigenen Technik zur Softwareentwicklung Vertiefende Informationen MuSofTLE 3.1 LM 3 Das Capability Maturity Model LE 3.1 LM 6 Prozessbeschreibung Studien und Diplomarbeiten

142 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 142 Ausgangsüberlegungen Softwarentwicklung ist ein komplexer Prozess, es gibt keine Kochbuchmethoden Software Ingenieure verbinden schöpferische Prozesse mit Ingenieurdisziplin Notwendig sind also –Erarbeitung grundlegender Prinzipien des SE Prozesses –Vermittlung von Methoden zur Definition der zu erledigenden Arbeit Messung des Erfolges Verbesserung des Vorgehens Das Capability Maturity Model sucht dazu Hilfestellung zu geben. Der Personal Software Prozess ist eine Variation für kleine Projekte

143 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 143 Das Capability Maturity Model (CMM) 1987 entwickelte das Software Engineering Institute (SEI) der Carnegie Mellon University im Auftrag des amerikanischen Verteidigungsministerium einen Fragebogen, mit dessen Hilfe die Leistungsfähigkeit von Software- Lieferanten bewertet werden sollte (Assessment). Der Fragebogen wurde zu einem Referenzmodell ausgebaut. Dieses Referenzmodell erhielt den Namen Capability Maturity Model (CMM). Den aktuellen Stand der Entwicklung findet man auf den Web-Seiten des SEI unter Publikationen. Das CMM gibt Hinweise, wie die Qualität des Software- Entwicklungsprozesse verbessert werden kann. Es werden fünf unterschiedliche Qualitätsstufen von Software-Entwicklungsprozessen unterschieden. Jede Qualitätsstufe beschreibt einen bestimmten Reifegrad (maturity) eines Entwicklungsprozesses. Die Stufen bauen aufeinander auf. Eine Stufe setzt voraus, dass die Anforderungen an die Prozesse, die die anderen Stufen erfordern, erfüllt sind.

144 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 144 Das Grundkonzept des Capability Maturity Modell

145 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 145 Reifegrade und Fähigkeiten im CMM (Übersicht) Die Prozessqualität der Software-Entwicklung bestimmt die Fähigkeiten (capabilities) eines Software-Unternehmens. Im CMM werden 5 Reifestufen (maturity) unterschieden, deren Prozessqualität wie folgt charakterisiert ist: StufeBezeichnungProzessqualität 1initial abhängig von Einzelpersonen 2repeatable diszipliniert 3defined standardisiert und konsistent 4managed vorhersagbar 5optimizing kontinuierlich verbessert

146 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 146 Entwicklung kleiner Systeme - Der PSP Der PSP (Personal Software Prozess) ist ein Weg zur individuellen Prozessverbesserung. Dies geschieht in enger Anlehnung an Capability Maturity Modell (CMM) des Software Engineering Institutes SEI der Carnegie Mellon University persönliches Management bedeutet, dass alle Schritte innerhalb des PSP vom Entwickler selbst durchgeführt werden müssen. Folgende Entwicklungsstufen werden unterschieden Repeatable: Projektplanung und -überwachung, Standardisierung durch Grundprozess (PSPO) Defined: Reviews, Prozessdefinition, Produktentwicklung, Qualitätsmanagement, quantitatives Prozessmanagement durch qualitätsorientierte Entwicklung (PSP2). Optimizing: Fehlervermeidung durch zyklische Entwicklung (PSP3)

147 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 147 Vorgehen Strukturierung der Abläufe Beschreibung der Workflows Verfügbarmachung von best practice Kontrolle der Ergebnisse Schaffung von Freiraum für Kreativität

148 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 148 Strategie zur Umsetzung des PSP Zur Umsetzung des PSP wird eine mehrstufige Strategie vorgeschlagen. Identifikation von Methoden und Techniken für große Systeme, welche auch für den persönlichen Gebrauch verwendet werden können. Definition einer Untermenge der gefundenen Methoden und Techniken für die Entwicklung kleiner Systeme. Strukturierung der Methoden für eine schrittweise Einführung. Bereitstellung von Übungen für die Methoden.

149 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 149 Durchführung des PSP Der Personal Software Process wird anhand von Skripten durchgeführt. Diese Skripte enthalten die für einzelne Aufgabenbereiche nötigen Anweisungen. Die Aufgabenbereiche werden schwerpunktmäßig Phasen (Reifegraden) zugeordnet. Folgende Phasen werden unterschieden: –Schwerpunkt Prozesssteuerung (PSPO) –Schwerpunkt Planung (PSP1) –Schwerpunkt Software-Entwicklung (PSP2) –Schwerpunkt Auswertungen (PSP3)

150 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 150 Der Grundprozess: PSPO Die erste Phase ist folgendermaßen charakterisiert: Verwendung des aktuellen Prozesses (z.B. Wasserfall) als Basis Einführung grundsätzlicher Größenmessungen Benutzung eines einfachen Rahmenwerks zur Erstellung kleiner Programme. Die Verbesserung des Prozesses wird durch die Aufzeichnung von Problemen und den Vorschlag von Änderungen eingeleitet. Dabei werden meist kleinere Änderungen vorgenommen (z.B. Anpassung der Struktur), um mit dem PSP kompatibel zu sein.

151 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 151 Metriken für den Grundprozess Um eine Prozessverbesserung erzielen zu können, sind u.a. Aussagen über den aktuellen Prozess und das erstellte Programm nötig: Erfassung der Programmgröße (hauptsächlich Zeilenzahl, da weit verbreitet und signifikante Korrelation zum Entwicklungsaufwand). Erfassung der Arbeitszeit pro Phase. Erfassung von Fehlern, die während der Entwicklung gemacht und behoben werden. Sammeln der erfassten Zeiten und Fehlerinformation über mehrere Projekte hinweg.

152 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 152 Ressourcen- und Ablaufplanung: PSP1 Im PSP1 wird zusätzlich zu den klassischen Phasen eine Planungsphase eingeführt. Alle Phasen werden zeitlich erfasst. Ziel ist die Einrichtung eines wiederverwendbaren Prozesses zur Schätzung von Ressourcenbedarf und Zeitaufwendungen. Die Hauptressource im PSP ist die Zeit. Zur Abschätzung des Zeitbedarfs werden folgende Daten herangezogen: –Vergangenheitsdaten für die Produktivität (Zeilen pro Stunde) –geschätzte Programmgröße –Vergangenheitsdaten für die aufgewendete Zeit. In der Ablaufplanung wird die Zeit pro Phase abgeschätzt, wobei hier zwischen Zeitbedarf, welcher von der Programmgröße abhängt und unabhängigem Zeitbedarf, unterschieden werden muss.

153 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 153 Metriken für den Entwicklungsprozess Die Überwachung des Entwicklungsprozesses wird mittels eines einfachen Indikators vorgenommen: –Der Anteil einer Aufgabe am Gesamtzeitbedarf des Projekts wird errechnet, –der Projektfortschritt ist gleich der Summe der bereits erledigten Anteile –der geplante Fortschritt wird mit dem tatsächlichen Fortschritt verglichen –bei groben Abweichungen müssen die geplanten Werte angeglichen werden. Zur Größenabschätzung wird die Zeilenzahl betrachtet. Möglichkeiten zur Abschätzung durch Experten in mehreren Runden. –Einteilung in grobe Kategorien aufgrund von Vergangenheitsdaten –Aufteilung des Programmes in Eingaben, Ausgaben, Anfragen, benutzte Dateien/Datenbanktabellen und externen Schnittstellen. –Abschätzung anhand von Proxies (Stellvertretern), z.B. Programm- Objekten.

154 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 154 Entwurf und Implementierung von Software: PSP2 Der Entwurf erfolgt in 4 Schritten, die aber nur selten linear durchlaufen werden: –Sammeln von Benutzeranforderungen –Analyse der Anforderungen –Erstellen eines High-Level Designs –Verfeinerung des Designs. Das Ergebnis des Entwurfs wird dokumentiert. Die Dokumentation soll die genaue Funktion des Programmes beschreiben. Folgende Gesichtspunkte sind zu beachten: –Beschreibung von Funktionen mittels Vorbedingungen und daraus resultierenden Aktionen (Funktionale Beschreibung) –Beschreibung der Interaktion des Benutzers mit dem Programm z.B. durch Use Cases (Operationale Beschreibung) –Beschreibung der Programm- oder Objektzustände (Zustandsbeschreibung) –Beschreibung von Funktionen mittels Pseudocode (Logische Beschreibung)

155 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 155 Metriken für Entwurf und Implementierung Fehler sollten möglichst früh vermieden werden. In dieser Phase sind dazu Prüfungen gegenüber Anforderungen in Form von Reviews hilfreich. Anforderunges-Reviews: –Prüfung des Designs gegen die Anforderungen und evtl. Einholen von weiteren Anforderungdsdaten. –Überprüfung von Syntax, Namensgebung, Speichermanagement, Funktionsaufrufen –Überprüfung auf Komplettheit, Programmlogik, Sonderfälle Für die Reviews sind Code- und Design-Standars zu entwickeln. Gegen diese kann dann geprüft werden.

156 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 156 Zyklische Prozesse: PSP3 Mit PSPO bis PSP2 lassen sich Programme bis ca Zeilen bewältigen. Für die Entwicklung größerer Programme muss das Gesamtsystem in handhabbare Einheiten zerlegt werden. Sie können dann nacheinander oder von einem Team parallel abgearbeitet werden. Der Entwicklungsprozess wird dazu aufgeteilt: Eine Planungs- und High-Level-Design- Phase sowie daran anschließend mehrere untergeordnete Phasen (zyklischer Prozess). Jeder Zyklus besteht aus einem kompletten PSP2-Prozess. Folgendes ist zu beachten: –Jeder Zyklus muss komplett und korrekt abgeschlossen sein (hohe Bedeutung für Design - und Code-Reviews), –Regressions-Tests sichern die Korrektheit aller Komponenten bei fortlaufenden Änderungen, –die im Zyklus bearbeiteten Änderungen sollten ca. 100 bis 300 Zeilen neuen und geänderten Code enthalten. Der PSP3 ist eine leicht praktizierbare Vorstufe des Rational Unified Process (RUP).

157 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 157 Test Maturity Model In Anlehnung an das CMM können 5 Reifestufen (maturity) unterschieden werden, um die Testqualität eines Unternehmens zu charakterisieren: StufeBezeichnungTestqualität 1initial (unsystematisch)abhängig von Einzelpersonen Qualität der SW schwankt 2repeatable (organisiert)diszipliniert Basisverfahren werden eingesetzt, hohe Fehlerraten bei Systemtests 3defined (kostensenkend)standardisiert und konsistent Testplan für alle Projekte durch QM, externe Tester für black box Tests 4managed (systematisch)vorhersagbar Einsatz von Tools und externen Testern, Analyse der Testergebnisse zwecks Prozessverbesserung 5optimizing (optimierend)kontinuierlich verbessernd

158 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 158 Weitere Informationen zum Capability Maturity Modell und seinen Ausprägungen Informationen zum CMM Informationen zum P-CMM Informationen zum Software Risk Management Informationen zum PSP Informationen zu SEPT (Software Engineering Process Technology) mit Liste der Standards und Normen zum Softwareengineering The Personal Software Process (CMU/SEI-2000-TR-022)

159 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 159 Praktikumsaufgaben - Block 9 Überprüfen Sie Ihr bisheriges Vorgehen anhand der Ergebnisse des Praktikums Entwickeln Sie Ihren persönlichen Softwareentwicklungsprozess

160 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 160 Versuch 10. Abschlussdiskussion Was würden wir das nächste mal besser machen Ziel: Erfahrungsaustausch mit Diplomanden und Doktoranden Schritt 1 Best Practise am IKE Schritt 2 Vorstellung einiger Arbeiten durch Diplomanden und Doktoranden Schritt 3 Was hat sich aus dem Praktikum bewährt Vertiefende Informationen Homepage der WN des IKEWN des IKE Vorlesung KS V6 Modellierung des Verhaltens - 1 KS V7 Modellierung des Verhaltens - 2 MuSoft LE 3.2 LM 8 ISO Normen

161 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 161 Techniken zum Bau komponentenbasierter Systeme Programmierung über Schnittstellen (Objekte kapseln spezielle Bedingungen) Verwendung von Programmiersprachen, die oo-Konstrukte enthalten (Java, C++) Verwendung von Case Tools, die oo-Konstrukte unterstützen (Eclipse) Verwendung von Klassenbibliotheken für Standardoperationen Verwendung von Produktmodellen für Komponentenbeschreibungen (semantische Anreicherung) Verwendung von Entwurfsmustern Verwendung von Frameworks

162 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 162 Software-Komponenten Eigenschaften in Bezug auf Bildung von Systemen –Ist in verschiedenen Kontexten einsetzbar (Wiederverwendung) –Kann gegen andere Komponente getauscht werden –Ist eindeutig identifizierbar –Besitzt Interkommunikationsfähigkeit - Einsatz über die Grenzen von Netzen, Sprachen, Protokollen, Adressräumen, Betriebssystemen und Werkzeugen hinweg –Besitzt klare Schnittstelle - Von Implementierung getrennt - Wohldefinierte Kommunikation mit Außenwelt –Ist keine vollständige Applikation –Ist frei kombinierbar mit anderen Komponenten

163 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 163 Wege der Wiederverwendung Wiederverwendung lässt sich auf drei unterschiedlichen Wegen erreichen: 1.Konfiguration vorhandener Bausteine: Die Komponenten werden als Black Box genutzt. 2.Ableitung von vorhandenen Bausteinen: Die Komponenten werden als White Box genutzt Intensive Kenntnis der White-Box-Komponenten ist notwendig. Es entstehen neue Komponenten, deren Funktionalität bisher durch existierende Bausteine nicht abgedeckt wurde. 3.Kombination von Bausteinen: Aus bereits existierenden Komponenten werden neue Komponenten erstellt (Mischung aus Black- und White-Box-Vorgehen).

164 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 164 Komponenten-Frameworks im Vergleich

165 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 165 J2EE via.Net: A quick comparison Performance.Net ist vor allem auf Windows Plattformen wesentlich effektiver als J2EE Community Ob und wie Nutzer die Entwicklung beeinflussen können ist offen. In 2002 war JCP offen genug, um Apache einzubinden Tools J2EE hat hier deutliche Vorteile (noch ?)..Net bietet zur Zeit nur Visual Studio.Net Multiplatform Support.Net nur in MS Welt (noch ?) benötigt man anderes als Windows, kommt nur J2EE in Frage Weitere Infos unter:

166 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 166 SIMPLAT ein Framework für technische Simulationen We develop SIMPLAT as a system for integration of scientific calculations in a problem domain in a specific context. There are many different applications in the same problem domain. Examples under investigation are: Problem domainContextApplication Dispersion of radioactive particlesEmergency caseABRKFUe Dispersion of radioactive particlesResearchABR research system Nuclear plant simulationTeachingVirtual power plant 1D: ViP1D Nuclear plant simulationResearchViP-PBMR Nuclear plant simulationVisualizationVirtual power plant 3D: ViP3D

167 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 167 Simplat - Simulation Platform User Management Simplat Session Management Simplat Request Management Protocol Service Application Cross- domain services Context dependent GUI Domain applications

168 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 168 Domain applications Data model for domain Service by component 1 Service by component 3 Service by component 4 Service by component 2 Service by component 5 Service by component 7 Service by component 6 Application 2 Application 1

169 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 169 Berichte aus der Praxis Entwicklung einer Übertragungskomponente für den Datenaustausch mit IFC von A. Schulz Erfahrungen mit transienten Verfahren in der Gebäudesimulation von J. Khan Studierende höherer Semester berichten über die Entwicklung ihres Softwareprozesses in 2003 sind 2 Berichte vorgesehen

170 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 170 CADdict AutoCad dxt Architektur CAD IFC FC - Parse DATAMODEL Gebäude Anlage IFC - Parse IFC Interface DATAMODEL Gebäude Anlage Zoniereng Messpunkte ZONE CAD (VEC) BUI DCK Annex36 ESC II VEC Planning VEC Controlling VEC Professional Energetische Bewertung Energiemanegemen t Fehlererkennung VDA (VEC) VEC EnEv IKEs integral validation and planning system

171 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 171 Simplat Simulation Framework ABR- Research ViP NumEx Simulationen Learning objects DB Help and Document DB File system for documents with special formats including code RDBS User model including role concept, logic, workflows, user session management. MuSofT Teacher Cocoon Lenya Content Mgmt. System Cocoon ClientSimpla t GISterm Browser PDF-Reader Client 1 Java Desktop Java Desktop Client 2 Computer supported Cooperative working IKE Lehr- und Lernumgebung

172 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 172 Praktikumsaufgaben - Block 10 Vorführung zweier Anwendungsbeispiele durch Teilnehmer des Praktikums –J. Khan: Integration eines transienten Simulationsprogrammes –A. Schulz: Transfer von CAD Daten in Energiesimulation Diskussion der Ansätze Bewertung der Ergebnisse

173 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 173 Ergebnis des Praktikums 02/03 Mit dem folgenden Java Programm kann der Verlauf des Wärmebedarfs über ein Jahr auf der Basis einer monatlichen stationären Energiebilanz bei einer konstanten Soll-Innentemperatur berechnet werden. Der Simulator ist als Java-Applet realisiert und benötigt etwas Zeit zum Laden der entsprechenden Dateien. Sie können die Programme auf Ihren lokalen Rechner herunterladen und dort ausführen: Dokumentation (dokumentation.zip)dokumentation.zip

174 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 174 Falls Sie mehr über Gebäude Simulation wissen wollen The U.S. Department of Energy is pleased to announce the availability of university course material for teaching building simulation using EnergyPlus. This course material is targeted specifically to the university environment for teaching students about building simulation while introducing them to EnergyPlus. The course comprises 25 complete PowerPoint lectures (over 800 total slides) which cover topics from strategies for using energy simulation, expectations, building input, primary and secondary systems, and advanced features. While many of the lectures deal explicitly with how to model various components and systems with EnergyPlus, the lectures also provide an appropriate overview of building systems so that the students can understand the context and purpose of the technology within the building. The presentations include text, graphics, photographs, color-coded input, and other features designed to make teaching and understanding the concepts of building energy analysis easier. The course material also includes notes to instructors about assumptions made when developing the course as well as a course outline/schedule to help the instructor organize the semester and homework assignments and projects. The course material is available at free of charge from the EnergyPlus web site. Those who download the course are simply requested to share feedback, example problems, experiences, etc. with DOE To download the materials, go to

175 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Folie 175 Quellcode des Praktikums 02/03 Quellcode - Simulation (source.zip)source.zip - Programmtest (source_test.zip)source_test.zip - Archive (JAR) (simulations.jar)(simulations.jar)


Herunterladen ppt "Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04."

Ähnliche Präsentationen


Google-Anzeigen