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.

Kopien: 1
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 Hauptfachpraktikum "Simulation komplexer technischer Anlagen" WS 03/04 Prof. Dr. Fritz Schmidt Dr. Darko Sucic unter Mithilfe von D. Georgieva 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 Ansprechpartner Vorlesung:Praktikum und Übungen: Prof. Dr. F. SchmidtDr. Darko 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 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 Software Process 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 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 Praktikum im Unified Process

6 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Das sollten Sie im Praktikum lernen Qualitätsgetriebene Softwareentwicklung als Basis des Baues virtueller Anlagen und deren Erkundung –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 Process 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 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 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 als Teil des Projekthandbuches 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 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 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 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 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 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 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 Beispielgebäude

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

17 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 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 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 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 Praktikumsaufgaben - Block 1 Erstellen Sie eine Liste der Aufgaben (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 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 Prozessmodelle 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 Unified 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 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 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 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 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 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 Zusammenspiel der Submodelle

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

30 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 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 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 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 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 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 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 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 Bitte beachten Sie auch die dort aufgeführten work guidelines 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 Video zum Einsetzen des RUP 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

39 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

40 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

41 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

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

43 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

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

45 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

46 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

48 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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)

49 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 Anstand V-Modell Guide (elektronischer Führer)

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

51 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

53 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

54 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

55 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

56 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Elemente eines Use Case-Diagramms Anwendungsfall A ist eine Variation vom Anwendungsfall B (Generalisierung) Akteur Anwendungsfall Der Anwendungsfall A ist ein Bestandteil vom Anwendungsfall B Der Anwendungsfall A erweitert an einer bestimmten Stelle den Anwendungsfall B

57 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

58 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

60 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

61 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Was ist OMONDO und was können wir damit tun Das folgende Videosoll die Modellierung eines kleinen Systems mit OMONDO veranschaulichen Wir sehen »Modellierung eines UseCase »Modellierung einer Wand »Modellierung der Energiebilanz einer Zone »Erstellung eines Modells aus Code

62 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

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

65 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

66 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

67 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

68 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Was ist und wozu verwenden wir Eclipse? Java VM Standard Java2 Virtual Machine Platform Eclipse Platform Java development tools JDTPDE Plug-in development environment Dieser Video wurde mit Originalmaterial von Eclipse und Anregungen aus den Tutorien von erstellt.

69 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

70 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

71 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

72 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

73 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

74 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

75 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

76 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

77 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

78 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

79 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Refactoring oder Nobody is perfect und es gibt (fast) nichts, was nicht anders gemacht werden könnte Videobasierte Einführung 800 = 8 * 100 = 100 * 8 = 25 * 32 = 5 2 * 2 5

80 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Was ist Refactoring? Refactoring ist ein systematischer Ansatz, durch eine Serie von kleinen Modifikationen das Design eines bestehenden objektorientierten Programms so zu verbessern, dass sich neue Funktionalitäten leichter implementieren lassen oder das Programm anschließend leichter wartbar ist. Bei Refactoring wird das externe Verhalten des Programmes nicht geändert, der Code erhält aber eine bessere interne Struktur.

81 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Warum Refactoring? Refactoring verbessert das Design der Software Refactoring macht die Software verständlicher Refactoring verbessert die Flexibilität Refactoring hilft Fehler zu finden Refactoring beschleunigt den Software- Entwicklungsprozess

82 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Wann soll Refactoring eingesetzt werden? Vor Hinzufügen einer neuen Funktionalität Vor und Nach dem Codereview Code Bed Smells als Wegweiser

83 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Bed Smells: If it stinks, change it - Kent Beck Bed Smell 1: Rule of three - Duplizierter Code –Beim ersten Mal wird der Code geschrieben. –Beim zweiten Mal kann der gleiche Code noch dupliziert werden. –Beim dritten Mal muss der Code umstrukturiert werden. Bed Smell 2: Lange Methode –Lange Methode macht den Code unübersichtlich Bed Smell 3: Große Klasse –besitzt viele Attribute und Methoden, erledigt die Arbeit von mehreren Klassen Bed Smell 4: Lange Parameterliste –Schwer zu verstehen und zu benutzen Bed Smell 5: Faule Klasse –Tut fast nichts, bringt unnötige Kosten Bed Smell 6: Kommentare –Kommentierter Code ist gut, selbstkommentierter Code ist besse

84 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Wie soll Refactoring eingesetzt werden? Test bei jedem Schritt –Unit-Test –white-box Test Ein Schritt auf einmal –Rückzugsmöglichkeit sichern (CVS, o.a.) –nicht debuggen, sonder zurückziehen Keine Funktionalität ändern Grundlegende Modifikationen: –Hinzufügen –Umbenennen –Löschen –Bewegen –Extrahieren –Ersetzen von Strukturelementen (Attributen, Klassen, Methoden )

85 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Refactoring Methoden Methode extrahieren –Zusammengehörigen Code in eine neue Methode extrahieren –Gegen: Duplizierter Code, Lange Methode, Kommentare Klasse extrahieren –Neue Klasse anlegen und Attribute und Methoden verschieben –Gegen: Duplizierter Code, Große Klasse Klasse integrieren –Attribute und Methoden in eine andere Klasse verschieben; Klasse löschen –Gegen: Faule Klasse Ganzes Objekt übergeben –Mehrere Parameter bilden eine natürliche Einheit –Gegen: Lange Parameterliste Schnittstelle extrahieren –Teilmenge der Methoden in eine Schnittstelle extrahieren –Gegen: Große Klasse

86 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Refactoring Methode: Schnittstelle extrahieren Problem –Verschiedene Klienten verwenden die gleiche Teilmenge der Schnittstelle einer Klasse, oder zwei Klassen haben einen Teil ihrer Schnittstellen gemeinsam Lösung –Extrahieren Sie die Teilmenge in eine Schnittstelle Motivation –Schnittstellen sind immer dann nützlich, wenn eine Klasse in verschiedenen Situationen unterschiedliche Rolle spielt. Verwenden Sie die Schnittstelle extrahieren für jede Rolle. Eine andere nützliche Anwendung dieser Refactoring Methode besteht darin die Importschnittstelle zu beschreiben. Vorgehen –Erstellen Sie eine leere Schnittstelle –Deklarieren Sie die gemeinsame Methode in der Schnittstelle –Lassen Sie die relevanten Klassen die Schnittstelle implementieren –Lassen Sie die Klienten die Schnittstelle verwenden

87 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Wann soll Refactoring nicht eingesetzt werden? Vom Refactoring ist abzuraten Kurz vor dem Abschlusstermin –Refactoring wird die Entwicklung über den Termin hinaus verlängern –Vorteile würden zu spät wirken wenn der Code zu schlecht ist –z.B. nicht übersetzbar oder nicht stabil lauffähig –Basis für stabiles Verhalten und Testbarkeit fehlt

88 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

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

91 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

92 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

93 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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....

94 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

95 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

96 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

98 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

99 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

100 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

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

103 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

104 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

106 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

107 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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)

108 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

109 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

111 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

112 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 :

113 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

114 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

115 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

116 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

117 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

118 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

119 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

120 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

121 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

122 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

123 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

124 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

125 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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)

126 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

127 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

128 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

129 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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)

130 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

131 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

132 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

133 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

134 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

135 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

136 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

137 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

138 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

139 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

140 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

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

143 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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!

144 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

145 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

146 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 (Annahme Vergleichsprogramm verfügbar) Ergänzen Sie das Projekthandbuch

147 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 Durchführung einer testgetriebener Entwicklung Schritt 2 Dokumentation der Ergebnisse Vertiefende Informationen VorlesungKS V5 Testgetriebene Entwicklung MuSoft LE 3.2 LM 14 Risikomanagement

148 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

150 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

151 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

152 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Versuch 9. Der Personal Software Process 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

153 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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 Process ist eine Variation für kleine Projekte

154 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

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

156 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

157 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Entwicklung kleiner Systeme - Der PSP Der PSP (Personal Software Process) ist ein Weg zur individuellen Prozessverbesserung. Dies geschieht in enger Anlehnung an Capability Maturity Model (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)

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

159 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

160 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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)

161 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

162 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

163 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

164 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

165 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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)

166 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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.

167 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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).

168 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

169 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Weitere Informationen zum Capability Maturity Model 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)

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

171 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

172 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

173 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

174 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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).

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

176 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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:

177 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

179 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

180 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Berichte aus der Praxis Entwicklung Erfahrungen Studierende höherer Semester berichten über die Entwicklung ihres Softwareprozesses in 2004 sind folgende Berichte vorgesehen

181 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

182 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

183 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Praktikumsaufgaben - Block 10 Vorführung zweier Anwendungsbeispiele durch Teilnehmer des Praktikums Diskussion der Ansätze Bewertung der Ergebnisse

184 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

185 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 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

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

187 Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE P MuSofT Erkundungsumgebung Entwicklung eines komponentenbasierten Systems WS 03/04 Quellcode des Praktikums 03/04 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