entwickelt werden konnten, multimedial gestaltet und evaluiert.

Präsentation zum Thema: "entwickelt werden konnten, multimedial gestaltet und evaluiert."—  Präsentation transkript:

1 entwickelt werden konnten, multimedial gestaltet und evaluiert.
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 Ansprechpartner Vorlesung: Praktikum und Übungen: Anschrift:
Prof. Dr. F. Schmidt Dr. 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 Inhalt Praktikum 19. - 30. 01. 04 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 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 Praktikum im Unified Process

6 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 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 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 Modellierungstufen Quantifizieren Diskretisieren Implementieren
Reale Komponente Verhalten M O D E L L I E R U N G Parameter Parameter Parameter physikalisches Modell Verhalten Quantifizieren mathematisches Modell Verhalten Diskretisieren numerisches Modell Verhalten Implementieren Simulationsmodell

10 Physikalisches Modell: Energiebilanz-Raum
Außenwand: Raum (Konvektion und Strahlung): Raum (Latent):

11 Mathematische Modelle für die Energiebilanz
Statische Verfahren (steady state) Lastberechnungen Erweiterte statische Verfahren (enhanced stady state) DIN V DIN EN 832 Dynamische Verfahren (non-stationary, transient) Differenzen und Finite-Elemente-Verfahren Response-Faktoren (Gewichtsfaktoren) Beuken-Modell Regeltechnisches-Ersatzmodell

12 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 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 Entwicklung des Problemverständnisses
Identifikation der wichtigsten Parameter Parametervariation bei einem Verfahren Vergleich verschiedener zeitlicher Auflösungen Grenzen der Modellierung bei vorgegebenen Parametern

15 Beispielgebäude

16 Beispielgebäude-Datenblatt

17 Physikalisches Modell
Zonenweise stationäre Energiebilanz bei vorgegebener Soll-Innentemperatur

18 Mathematisches Modell
Statisches Verfahren auf monatlicher Basis mit folgenden Gleichungen: Transmissionsverluste: Lüftungsverluste: Interne Wärmegewinne: Mittlere interne Wärmegewinne auf der Basis eines durchschnittlichen 2,7-Personenhaushaltes bezogen auf die Wohnraumfläche Solare Wärmegewinne:

19 Numerisches Modell Transmissionsverluste: Lüftungsverluste:
Interne Wärmegewinne: Solare Gewinne: , dann sind die obigen Gleichungen für jeden Monat zu lösen und die monatlichen Werte von aufzusummieren

20 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 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 Text: Wie setzt man Use Cases ein

22 Versuch 2 Wie wollen wir das tun - UML + Projekthandbuch
Vorgehensmodelle Ziel: Erstellung des Projekthandbuches für das Praktikum Schritt 1 Das Problem - Einführung in das V-Modell Schritt 2 Video zur Einführung in den RUP Schritt 3 Modellierung des Praktikums mit ProModUP Schritt 4 Anlegen eines Projekthandbuch Schritt 5 Beschreibung der Aufgabe für dieses Praktikum in Projekthandbuch Vertiefende Informationen Vorlesung KS V3 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 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 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 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 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 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 Zusammenspiel der Submodelle

29 Submodell Systemerstellung

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

31 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 Kernaktivitäten und -Produkte des Submodells Softwareentwicklung
Systemanforderungsanalyse Systementwurf Softwareanforderungsanalyse Softwaregrobentwurf Softwarefeinentwurf Softwareintegration Softwareimplementierung Systemintegration Nutzerfreigabe Produkt Anwenderforderungen Systemarchitektur Technische Anforderungen Softwarearchitektur Softwareentwurf Module und Datenbanken Softwareeinheiten System Installiertes System

33 Beispiel: Wasserfallmodell als einfaches Phasenmodell
Voraussetzungen: Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) Bekannte Technologien und Verfahren Analyse Design Kodierung Test Aktivitäten Produkte: Schwerpunkt im Praktikum Spezifikation Tag 1 Entwurf Tag 2 Programm Tag 3 und 4 Abnahmebericht - Tag 5

34 Teil-Submodell Softwareentwicklung
V-Modell der Software-Entwicklung (Thaller: ISO 9001) zeigt die Verbindung von Prozessmodell und Qualitätssicherung

35 Rational Unified Process (RUP) - Definitionen
Dem Rational Unified Process (RUP) liegt ein best practice objektorientiertes Modell zu Grunde. Der RUP definiert sich über Workflows, die parallel und in Phasen ablaufen. Innerhalb jeder Phase sind Iterationen und inkrementelle Verbesserungen möglich. Zur Definition der Workflows stehen im RUP eine Reihe von Hilfsmitteln zur Verfügung (Schlüsselkonzepte), die miteinander wechselwirken. Zum Beispiel werden Aktivitäten von Workers erbracht, die dadurch Artefakte produzieren. Zur Gestaltung der Artefakte werden Guidelines und Templates zur Verfügung gestellt.

36 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 Entwurf Einführung Konzeption Realisierung Iterationen umfassen jeweils alle Workflows einer Phase

37 Wir wünschen viel Erfolg
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. Bitte beachten Sie auch die dort aufgeführten work guidelines Wir wünschen viel Erfolg

38 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.

39 Submodell Qualitätssicherung
QS-Initialisierung Prozessprüfung von Aktivitäten Durchführungs- entscheidung Prüfung vorbereiten Fertigprodukt prüfen QS-Berichtswesen Produkt prüfen

40 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 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 Submodell Projektmanagement
Projekt initialisieren Hauptaktivität initialisieren Hauptaktivität begleiten Hauptaktivität abschließen Dies sind Aufgaben der Praktikumsleiter Projekt abschließen

43 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 Submodell Konfigurationsmanagement
KM-Initialisierung Konfigurations- verwaltung Änderungs- management KM-Berichtswesen Datensicherung Hierzu kurze Einführung in CVS

45 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 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: Dies ist die Basis für das Verständnis der entsprechenden Übungsumgebung

47 Projekt Studienarbeit im V Modell
Link: Projekt Studienarbeit

48 Zum Nachlesen und zur aktuellen Information
Kurzfassung Vorgehensmodell V-Modell Handbuch Musterprojekt kleine Vorhaben Musterprojekt große Vorhaben Vorlage Projekthandbuch Praktikum Lehrbuch (Unified Process der Uni Dortmund)

49 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 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 Vorlage Projekthandbuch Praktikum Übertragen Sie Lasten und Pflichtenheft in das Projekthandbuch

51 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 Ergebnis der Analyse Statisches, monatliches Berechnungsverfahren
Berechnung Wärmebilanz für Standardzone vorhanden Erweiterung des Frameworks um die im Lastenheft beschriebenen Methoden

53 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 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 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 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 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 Elemente eines Klassendiagramms
Vererbung: Klasse A erbt von der Klasse B Abhängigkeit: Klasse A hängt von der Klasse B in irgendeiner Art und Weise ab (z.B. A nutzt Attribute von B Assoziation: Klassen A und B stehen in einer Beziehung zu einander Aggregation: Klasse A beinhaltet die Klasse B Achtung: Die Implementierung dieser Elemente hängt vom Programmiermodell der verwendeten Programmiersprache ab

59 Das RENSim Framework

60 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 unter „The use of EMF by Eclipse (more ...)“ Diese Einführung liegt dieser und folgender Einheit zur Grunde.

61 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 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 Weitere Informationen und Werkzeuge zu UML
Offizielle UML Suite der OMG Link Sammlung zum Thema UML Werkzeug Vergleich Standardisierungspartner

64 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 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 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 opens 2002 June - Eclipse 2.0 ships September - Eclipse ships November - Eclipse ships 2003 March - Eclipse 2.1 ships

67 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 Was ist und wozu verwenden wir Eclipse?
PDE Plug-in development environment Java development tools JDT Platform Eclipse Platform Java VM Standard Java2 Virtual Machine Dieser Video wurde mit Originalmaterial von Eclipse und Anregungen aus den Tutorien von erstellt.

69 Eclipse Overview Platform Runtime Eclipse Project Another Tool
Eclipse Platform Java Development Tools (JDT) Workbench Help JFace SWT Team Your Tool Plug-in Development Environment (PDE) Workspace Debug If you only get to show one slide, this is the one that best captures “The Big Picture”. Platform Runtime Their Tool Eclipse Project

70 Eclipse Plug-in Architecture
Typical arrangement plug-in A plug-in B extension point P contributes extension implements interface I class C 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 creates, calls

71 Eclipse Platform Eclipse Platform is the common base
Consists of several key components Platform Runtime Eclipse Platform “Core” “UI” Workbench Team Help Debug JFace SWT [Contains animated elements] Workspace Ant

72 Workspace Component Tools operate on files in user’s workspace
Workspace holds 1 or more top-level projects Projects map to directories in file system Tree of folders and files {Files, Folders, Projects} termed resources Tools read, create, modify, and delete resources in workspace Plug-ins access via workspace and resource APIs

73 Workbench Component SWT – generic low-level graphics and widget set
JFace SWT SWT – generic low-level graphics and widget set JFace – UI frameworks for common UI tasks Workbench – UI personality of Eclipse Platform

74 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 How small? SWT is about 200 classes, with a 200 KB native library. By comparison, AWT/Swing is about 1000 classes, with a 1 MB native library.

75 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 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 Workbench Terminology
Menu bar Message area Editor Status Text editor Tool bar Perspective and Fast View bar Properties view Tasks Outline Bookmarks Resource Navigator view [Contains animated elements] Stacked views

78 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 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 = 52 * 25

80 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 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 Wann soll Refactoring eingesetzt werden?
Vor Hinzufügen einer neuen Funktionalität Vor und Nach dem Codereview „Code Bed Smells“ als Wegweiser

83 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 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 Refactoring Methoden Methode extrahieren Klasse 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 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 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 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 Spezifikation Basis-Berechnungsframework vorhanden
Analyse des Frameworks mit Eclipse Erweiterung des Frameworks im Sinne des Pflichtenhefts

90 Praktikumsaufgaben - Block 4
Arbeiten Sie sich in Java ein Entwickeln Sie eine Klasse. Ergänzen Sie das Projekthandbuch

91 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 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 Project Leader

93 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 Rollen Fachwissen Architekt Technologie Domänenexperte Anwendungsbereiche Projektleiter Organisation Qualitätsmanager Projektziele Weitere Rollen Fachwissen Systemanalytiker Designer Programmierer ....

94 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 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 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 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 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 Vorlesung KS 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 LM 12 Funktionstests LE 3.2 LM 13 Abnahmetests

99 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 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 Fehlerbehebungskosten

102 Fehlerbehebungskosten

103 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 Anforderungen und/oder Erwartungen an das Produkt PROZESS Merkmale und Eigenschaften des Produktes Anweisungen Ausführung Prozessqualität

104 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 Durch Verification / Validation zur Produktqualität
Customer needs Specs Draft standards Drafting process For the purpose of this presentation Verification: Comparison of revised standards with approved specification Validation: Comparison of revised standards with user needs (results of survey) Commit audience to participation in validation process through national standards bodies VALIDATION

106 Beispiel: Wasserfallmodell als einfaches Phasenmodell
Voraussetzungen: Stabiles Umfeld (z.B. keine Änderungen der Anforderungen) Bekannte Technologien und Verfahren Aktivitäten 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

107 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 Fehlerreduktion durch Testen beim Wasserfallmodell
Analyse Design Kodierung Test 20 nach 5 40 nach 10 Kodierung Unit Test Integration Test System Test 100 nach 15 50 nach 7 20 nach 3 10 nach 1 Zahlen nach Wheeler bezogen auf je 1000 lines of code

109 Iterative-Inkrementelle Vorgehensmodelle (1)
Annahmen: Anforderungen sind unvollständig wichtige Erkenntnisse werden erst im Laufe des Projektes gewonnen Analyse Design Iteration 1 Kodierung Test 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) Iteration 2 Iteration N Eine Unterstützung durch datenbankgestützte Tools wird notwendig

110 Teil-Submodell Softwareentwicklung
V-Modell der Software-Entwicklung (Thaller: ISO 9001)

111 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 Entwurf Einführung Konzeption Realisierung Iterationen umfassen jeweils alle Workflows einer Phase

112 Durch Softwareprüfung zu Produktqualität
dynamische Prüfung statische Prüfung Test Leistungsmessung : mit Hilfe des Rechners ohne Hilfe des Rechners Prüfung gegen Regeln Konsistenzprüfung Quantitative Untersuchung : Review :

113 Softwareprüfung und Fehlerbehebung
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 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 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 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 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 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 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 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 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 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 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 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 Unit Tests (Einzeltests)
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

126 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 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 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 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 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 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 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 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 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 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 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 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 Prüfung objektorientierter Programme -2
Vorgehen anhand eines Beispiels Architektur des Beispiels D C C1 F B A2 A1 E2 E1 E A x Y X erbt von Y x Y X benutzt Y

139 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 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 JUnit Framework

142 Anwendung des JUnit Frameworks zum Systemtest
Abnahmetests (LM13) Integrationstests (LM11) Funktionstests (LM12) Einzeltests (LM10)

143 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 Testing Frameworks im Internet
Testing Framework (xUnit, unit testing) Kent Beck‘s Orginal Test Framework Paper Xunit testing frameworks Bugzilla Automatisches Unit Testing Unit Teating mit Junit by F. Westphal Download Junit 3.8.1

145 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 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 ergaben 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 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 Vorlesung KS V5 Testgetriebene Entwicklung MuSoft LE 3.2 LM 14 Risikomanagement

148 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 Praktikumsaufgaben - Block 7
Implementierung der Entwürfe Durchführung der Tests Ändern der Methode

150 Erstellung der neuen Version des RENARCH applets
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 3 Abnahme der Artefakte Schritt 4 Diskussion der Ergebnisse mit dem Auftraggeber Vertiefende Informationen Excel Programm zur Berechnung des Energiebedarfes von Wohngebäuden

151 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 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 MuSofT LE 3.1 LM 3 Das Capability Maturity Model LE 3.1 LM 6 Prozessbeschreibung Studien und Diplomarbeiten

153 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 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 Das Grundkonzept des Capability Maturity Model

156 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: Stufe Bezeichnung Prozessqualität 1 initial abhängig von Einzelpersonen 2 repeatable diszipliniert 3 defined standardisiert und konsistent 4 managed vorhersagbar 5 optimizing kontinuierlich verbessert

157 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 Vorgehen Strukturierung der Abläufe Beschreibung der Workflows
Verfügbarmachung von best practice Kontrolle der Ergebnisse Schaffung von Freiraum für Kreativität

159 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 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 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 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 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 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 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 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 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 Test Maturity Model In Anlehnung an das CMM können 5 Reifestufen (maturity) unterschieden werden, um die Testqualität eines Unternehmens zu charakterisieren: Stufe Bezeichnung Testqualität 1 initial (unsystematisch) abhängig von Einzelpersonen Qualität der SW schwankt 2 repeatable (organisiert) diszipliniert Basisverfahren werden eingesetzt, hohe Fehlerraten bei Systemtests 3 defined (kostensenkend) standardisiert und konsistent Testplan für alle Projekte durch QM, externe Tester für black box Tests 4 managed (systematisch) vorhersagbar Einsatz von Tools und externen Testern, Analyse der Testergebnisse zwecks Prozessverbesserung 5 optimizing (optimierend) kontinuierlich verbessernd

169 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 Praktikumsaufgaben - Block 9
Überprüfen Sie Ihr bisheriges Vorgehen anhand der Ergebnisse des Praktikums Beschreiben Sie Ihren persönlichen Softwareentwicklungsprozess

171 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 IKE Vorlesung KS V6 Modellierung des Verhaltens - 1 KS V7 Modellierung des Verhaltens - 2 MuSoft LE 3.2 LM 8 ISO Normen

172 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 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 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 Komponenten-Frameworks im Vergleich

176 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 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 domain Context Application Dispersion of radioactive particles Emergency case ABRKFUe Dispersion of radioactive particles Research ABR research system Nuclear plant simulation Teaching Virtual power plant 1D: ViP1D Nuclear plant simulation Research ViP-PBMR Nuclear plant simulation Visualization Virtual power plant 3D: ViP3D

178 Simplat - Simulation Platform
Context dependent GUI Simplat Session Management User Management Protocol Service Cross-domain services Simplat Request Management Application Application Domain applications

179 Domain applications Application 1 Application 2 Service by component 5
Data model for domain

180 Berichte aus der Praxis
Studierende höherer Semester berichten über die Entwicklung ihres Softwareprozesses in 2004 sind folgende Berichte vorgesehen Entwicklung Erfahrungen

181 IKE‘s integral validation and planning system
IFC Architektur CAD IFC FC - Parse DATAMODEL IFC - Parse IFC Gebäude AutoCad dxt Anlage ZONE CAD (VEC) CADdict Annex36 BUI Energetische Bewertung EnEv VEC Planning Interface DCK DATAMODEL VEC Controlling Energiemanegement VEC 832 Gebäude Anlage VEC Professional Fehlererkennung 2067 Zoniereng Messpunkte ESC II VDA (VEC)

182 IKE Lehr- und Lernumgebung
User model including role concept, logic, workflows, user session management. Teacher MuSofT Lenya Content Mgmt. System Cocoon ClientSimplat GISterm Browser PDF-Reader Client 1 Java Desktop Client 2 Computer supported Cooperative working 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

183 Praktikumsaufgaben - Block 10
Vorführung zweier Anwendungsbeispiele durch Teilnehmer des Praktikums Diskussion der Ansätze Bewertung der Ergebnisse

184 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)

185 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 Quellcode des Praktikums 02/03
- Simulation (source.zip) - Programmtest (source_test.zip) - Archive (JAR) (simulations.jar)

187 Quellcode des Praktikums 03/04
- Simulation (source.zip) - Programmtest (source_test.zip) - Archive (JAR) (simulations.jar)