SWT ZUSAMMENFASSUNG ~~~~~~~~~~~~~~~~~~~ von Andreas Leppert V1.0 - erste Version V1.1 - Saetze verbessert, Rechtschreib- und Stilfehler korrigiert, teilweise Abkuerzungen ausgeschrieben V1.2 - XML und CVS ausgearbeitet V1.4 - Optimierungen erweitert und aktualisiert V1.5 - Qualitaetssicherung angepasst (Integrationstest erweitert) made with vim because emacs sucks! +~~~~~~~~~~~~~+ + EINFUEHRUNG + +~~~~~~~~~~~~~+ WAS IST SOFTWARE ? * Definitionen von Software: + Sammelbezeichnung fuer Programme, die fuer den Betrieb von Rechensystemen zur Verfuegung stehen, einschliesslich der zugehoerigen Dokumentation + die zum Betrieb einer DV-Anlage erforderlichen nichtapparativen Funktionsbestandteile + unter Software subsumiert man alle immateriellen Teile, d.h. alle auf einer DV-Anlage einsetzbaren Programme + Menge von Programmen oder Daten zusammen mit begleitenden Dokumenten, die fuer ihre Anwendung notwendig oder hilfreich sind + Computer programs, procedures, rules and possibly associated documentation and data pertaining to the operation of a computer system (IEEE) - umfassender Begriff - enthaelt Dokumentation - immaterieller Charakter von Software - Beispiele fuer Programme: Quellcode, Zwischencode, Objektcode, Bibliotheken, Rahmenarchitekturen, Installationsprogramme, Testprogramme - Beispiele fuer Daten: Initialisierungsdaten, Hilfsinformation, Fehler, Dialogtexte - Beispiele fuer Dokumentationen: Anforderungsdokumentation, Architekturbeschreibung, Funktionsbeschreibungen der Klassen/Methoden, Test- und Abnahmeprotokolle, Benutzerhandbuecher, Onlinehilfen * Produkt: + ein in sich abgeschlossenes, i.a. fuer einen Auftraggeber bestimmtes Ergebnis eines erfolgreich durchgefuehrten Projekts oder Herstellungsprozesses * Software-Produkt: + Produkt, das aus Software besteht * System: + Ausschnitt aus der realen oder gedanklichen Welt, bestehend aus Gegenstaenden und darauf vorhandenen Strukturen - Systeme bestehen aus Systemkomponenten (Teilen von Systemen), die untereinander in verschiedenen Beziehungen stehen koennen - Systemteile, die nicht weiter zerlegbar sind oder zerlegt werden sollen, werden als Systemelemente bezeichnet * Software-System: + System, dessen Systemkomponenten aus Software bestehen * Software, Software-Produkt, Software-System: - Software ist der allgemeinste, neutralste Begriff - Software-Produkt betrachtet die Software von außen, aus Kaeufer-/ oder Auftraggebersicht - Software-System betrachtet Software von innen, aus Entwicklersicht * Unterteilung der Software + Systemsoftware (Achtung: ungleich Softwaresystem) - a.k.a. Basissoftware - entwickelt fuer spezifische Hardware-Geraete um damit umgehen zu koennen - Beispiele: Betriebssysteme, Compiler, Datenbanken, Kommunikationsprogramme und spezielle Dienstprogramme + Anwendungssoftware - a.k.a. Applikationssoftware - werden benutzt um Aufgaben des Anwenders zu erledigen - basiert auf Systemsoftware * Unterscheidung Computer-System und technisches System + Computersystem bzw. DV-System - entspricht Anwendungssoftware, Systemsoftware plus Hardware - Beispiel: Bordrechner im Flugzeug + technisches System - Computersystem plus weitere technische Einrichtungen - Beispiel: Flugzeug an sich * Unterscheidung zwischen Software-Entwicklung und System-Entwicklung + Software-Entwicklung: ausschließliche Entwicklung von Software + System-Entwicklung: Entwicklung eines Systems bestehend aus Software und Hardware WARUM IST SOFTWARE SO SCHWER ZU ENTWICKELN ? * Eigenschaften von Software - Software ist immaterielles Produkt (man sieht sie nicht, man kann sie nicht anfassen) - Software unterliegt keinem Verschleiss - Software nicht begrenzt durch physikalische Grenzen - Software im Allgemeinen leichter und schneller aenderbar als technisches Produkt (falls gut strukturiert) - keine Ersatzteile fuer Software - Software altert (weil sich Umgebung aendert) - Software ist schwer zu vermessen * Veraenderungen der Software in den letzten 20 Jahren + zunehmende Bedeutung - eigenstaendiges Wirtschafsgut - Bestandteil der meisten technischen und Dienstleistungs-Produkte + wachsende Komplexitaet - immer mehr Anwendungsgebiete - immer mehr schwierigere Aufgaben sollen geloest werden + zunehmende Qualitaetsanforderungen - Versagen gleichgesetzt mit wirtschaftlichem Versagen - 50% der Ausfaelle im industriellen Sektor aufgrund von Software-Fehlern - Beispiel: TollCollect, Flughafen Denver + Nachfragestau und Engpassfaktor - immer mehr Software wird verlangt, aber langsamere Produktivitaetssteigerung und zu wenige Software-Ingenieure -> Engpassfaktor der Informationstechnik + mehr Standardsoftware - aufgrund hoher Kosten von Individualsoftware und Nachfragestau von Software - fuer Standardsoftware spricht: - wenn Anforderungen standardisiert sind (ReWe, ...) - Integration verschiedener Module - kostenguenstiger als Individualsoftware - weniger fehleranfaellig als Individualsoftware - fuer Individualsoftware spricht: - Anpassungskosten von Standardsoftware uebersteigt i.a. Kosten der Individualsoftware - vorhandene Anwendungen koennen nur schwer in Standardsoftware eingebaut werden - Standardsoftware oft nur fuer mittel- bis große Unternehmen + zunehmend "Außer Haus" - Entwicklung + zunehmend Altlasten - Anpassungsprozesse noetig wegen Aenderung der Einsatzumgebung WARUM IST MARKTREIFE SOFTWARE SO SCHWER ZU ENTWICKELN ? * vier Anforderungen sollten erfuellt werden + Funktionstreue - Uebereinstimmung der definierten Produktanforderungen mit dem fertiggestellten Produkt + Qualitaetstreue - Uebereinstimmung der definierten Qualitaetsanforderungen mit dem fertiggestellten Produkt + Termintreue - Einhaltung des Entwicklungplans + Kostentreue - Einhaltung des in der Wirtschaftlichkeitsrechnung geplanten Personal- und Sachaufwands fuer die Produkterstellung und -pflege * entwickelt man heute Anwendungssoftware, dann bedeutet dies, dass + waehrend der Lebenszeit der Anwendungssoftware mindestens einmal die zugrunde liegende Systemsoftware und mindestens zweimal die Hardware ausgetauscht wird + die Zielsysteme zur Zeit der Entwicklung oft noch nicht vorhanden sind + laenderspezifische Varianten der Software benoetigt werden WAS IST SOFTWARE-TECHNIK? * Definitionen: + systematic approach to the development, operation, maintenance and requirement of software + practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate and maintain them + ingenieurmaessiges Entwerfen, Herstellen und Implementieren von Software sowie die ingenieurs-wissenschaftliche Disziplin, die sich mit den Methoden und Verfahren zur Loesung der damit verbundenen Problemstellungen befasst + zielorientierte (Beruecksichtiung von Kosten, Zeit, Geld, Qualitaet, ...) Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen fuer die arbeitsteilige, ingenieurmaessige Entwicklung und Anwendung von umfangreichen Software-Systemen + Tichy: Softwaretechnik ist die technologische und organisatorische Disziplin zur systematischen Entwicklung und Pflege von Software-Systemen, die spezifizierte funktionale und Qualitaetsattribute erfuellt + Softwareforschung ist die Bereitstellung und Bewertung von Methoden, Verfahren und Werkzeugen fuer die Softwaretechnik * Unterscheidung von Software-Entwicklung, Software-Wartung und Software-Pflege + Entwicklung: Produkt definieren, planen, entwerfen, implementieren, etc. Einhaltung der Forderungen des Kunden + Wartung bedeutet, ein nach der Inbetriebnahme auftretendes Fehlverhalten zu beseitigen + Pflege bedeutet, ein Produkt an geaenderte Bedingungen anzupassen oder aufgrund neuer oder geaenderter Anforderungen weiterzuentwickeln * Ueberblick: + Planung -> Definition -> Entwurf -> Implementierung -> Testen & Abnahme -> Einsatz und Wartung +~~~~~~~~~~~~~~~+ + Planungsphase + +~~~~~~~~~~~~~~~+ LERNZIELE * Zweck des Lastenhefts beschreiben koennen * Anforderungstypen unterscheiden koennen * Lastenheft fuer vorgegebene Aufgabenstellungen entsprechend dem Schema erstellen koennen * Anforderungsermittlungstechniken erlaeutern koennen EINFUEHRUNG UND UEBERBLICK * Voruntersuchung oder Durchfuehrbarkeitsuntersuchung + vor der eigentlichen Entwicklung muss fachliche, wirtschaftliche und personelle Durchfuehrbarkeit gezeigt werden - am Ende wird also entschieden, ob man das Projekt entwickelt oder nicht ("stop or go") * durchzufuehrende Aktivitaeten + Auswaehlen des Produkts - Trendstudien - Marktanalysen - Kundenanfragen - Vorentwicklungen + Voruntersuchung des Produkts - Festlegung der Hauptanforderungen (Hauptfunktionen, Hauptdaten, Hauptleistungen, wichtigsten Aspekte der Benutzungsschnittstelle, Qualitaetsmerkmale) - Ist-Aufnahme falls Vorgaengerprodukt existiert, anschliessend Ist-Analyse + Durchfuehrbarkeitsuntersuchung - pruefen der fachlichen Durchfuehrbarkeit (softwaretechnische Realisierbarkeit, Verfuegbarkeit von Entwicklungs- und Zielmaschinen, ...) - pruefen alternativer Loesungsvorschlaege (Beispiel: Anpassen von Standardsoftware oder Individualsoftware) - personelle Durchfuehrbarkeit - pruefen der Risiken - Aufwands- und Terminabschaetzung - Wirtschaftlichkeitsrechnung -> Ergebnis ist die Durchfuehrbarkeitsstudie (feasibility study) bestehend aus (i) Lastenheft (grobes Pflichtenheft) (ii) Glossar (Begriffslexikon) (iii) Projektkalkulation (iv) Projektplan * Rollen in der Planungsphase + Auftraggeber - gibt Anforderungen vor und nimmt Ergebnisse der Durchfuehrbarkeitsstudie an - wirkt mit bei (i) - (iv) + Projektleiter - plant, steuert und kontrolliert Projekt - verantwortlich fuer (iii) und (iv), mitwirkend bei (i) und (ii) + Anwendungsspezialist - fachgerechte Beschreibung der Anforderungen des Auftraggebers - verantwortlich fuer (i) und (ii), mitwirkend bei (iii) und (iv) LASTENHEFT UND GLOSSAR * Ergebnisdokument der Planungsphase nennt man Lastenheft, ergaenzt um den Glossar (weiterhin Projektkalkulation, Projektplan) + beschreibt Eigenschaften, die das Produkt aus der Sicht des Kunden erfuellen soll - funktionale Eigenschaften (Dienste, die das Produkt zur Verfuegung stellt) - nichtfunktionale Eigenschaften (Einschraenkungen der Dienste, Antwortzeitverhalten, Standards, Zuverlaessigkeit, ...) - Qualitaetsanforderungen (Benutzbarkeit, Leistung, Speicherplatzbedarf, Zuverlaessigkeit, Portierbarkeit, ...) - externe Eigenschaften (Interoperabilitaet, Standards, gesetzliche Vorschriften, ethische Anforderungen, ...) + Lastenheft dient der Kommunikation mit Kunden und der Projektplanung + Pflichtenheft ist Vorschrift fuer Entwickler * Gliederungsschema eines Lastenheftes (9 Punkte) + Zielbestimmung - Beschreibung der Ziele welche durch Einsatz des Produkts erreicht werden sollen + Produkteinsatz - welche Anwendungsbereiche und fuer welche Zielgruppe + Produktuebersicht - meist grafischer Ueberblick ueber die Produktumgebung, z.B. Umweltdiagramm + Produktfunktionen - Hauptfunktionen (typische Arbeitsablaeufe werden hier beschrieben), die zu Ergebnis fuer den Benutzer fuehren - keine Auffuehrung von Verwaltungsfunktionen (z.B. loeschen eines Kunden etc.) - wichtigsten Funktionen, die Berichte, Reports, Listen erstellen - Funktionen werden so markiert (in Zehnerschritten): /LF 20/ - Ermittlung der Funktionen durch Akteure / Geschaeftsprozesse oder mit Schnittstellen / Datenfluessen + Produktdaten - langfristig gespeicherten Hauptdaten werden hier aufgelistet + Produktleistungen - wenn Leistungsanforderungen an die Funktionen gestellt wird (z.B. bzgl. Zeit, Genauigkeit etc.), dann werden sie hier aufgefuehrt - markiert durch: /LLnn/ + Qualitaetsanforderungen - wichtigsten Qualitaetsanforderungen werden hier aufgelistet - z.B. gute Zuverlaessigkeit, gewisse Geschwindigkeit, gutes Antwortverhalten etc. + Ergaenzungen - aussergewoehnliche Anforderungen (z.B. Spracheingabe muss moeglich sein) und normale Ergaenzungen fallen in diese Kategorie + Glossar * Aufgabe des Lastenhefts + Zusammenfassung aller fachlichen Basisanforderungen (fundamentale Eigenschaften des Produkts) + gerichtet an Auftraggeber, Projektleiter, Anwendungsspezialist + erste grobe Beschreibung des zu erstellenden Produkts + Erstellung durch - outside-in-Methode (erst wird Umwelt modelliert, dann Produktinterna) - inside-out-Methode (zunaechst Produktinterna, dann Umwelt) - Beispiele fuer outside-in-Methode: - Akteure und Geschaeftsprozesse (Geschaeftsprozessdiagramm, objektorientiert Software-Entwicklung) - Schnittstellen und Datenfluessen (Kontextdiagramm, strukturierte Software-Entwicklung) * Glossar + parallel zum Lastenheft wird Glossar erstellt - enthaelt alle Begrifflichkeiten zur Beschreibung des Produkts ANFORDERUNGSERHEBUNG UND -VALIDIERUNG * Ausgangspunkt ist Problem, das geloest werden soll + Unzufriedenheit mit dem Ist-Zustand + neue Geschaeftsidee + Einsparung von Kosten / Zeit / Ressourcen + Anforderungsermittlung durch Experten im Anwendungsbereich - Journalistentechnik der W-Fragen - Was ist das Problem ? (identifiziere Problem) - Wessen Problem ist es ? (identifiziere Betroffene) - Wo ist das Problem ? (verstehe Kontext, Anwendungsdomaene) - Warum muss es geloest werden ? (identifiziere Ziele der Betroffenen) - Wie koennte eine Software-Loesung helfen ? (sammle Anwendungsfaelle) - Wann muss das Problem geloest werden ? (identifiziere Entwicklungseinschraenkungen) - Was koennte eine Loesung verhindern ? (bestimme Machbarkeit und Risiko) * Erhebungstechniken + Introspektion - denke scharf nach, was Anforderungen sein koennten + Dokumenten- / Datenanalyse - finde Sammlung von Dokumenten/Daten + Interviews - strukturiert, offen, direktes Gespraech + Umfragen / Frageboegen + Gruppentechniken - Joint/Rapid Application Development (JAD/RAD), Anforderungen an ein System werden in strukturierten Sitzungen von Benutzern und Entwicklern festgelegt - Fokusgruppen (Sammlung von Meinungen einiger Leute) - Brainstorming + Anwendungsfaelle - Beschreibung einer Folge von Aktionen eines Systems, die Ergebnis fuer Aktor liefert + Ethnografie - Beobachter wird Teil der Gruppe, arbeitet in ihr und schreibt Arbeitsweise der Gruppe auf * anschliessende Anforderungsvalidierung (vor der Fertigstellung) + Korrektheit - Anforderungen geben die Sicht des Kunden richtig wider + Vollstaendigkeit - alle Situationen sind beschrieben, keine Luecke + Konsistenz - keine funktionalen oder nichtfunktionalen Anforderungen widersprechen sich + Realisierbarkeit - Anforderungen koennen erfuellt werden + Rueckverfolgbarkeit - moeglich, jede Systemfunktion einer oder einer Menge von Anforderungen zuzuordnen, die die Funktion benoetigen +~~~~~~~~~~~~~~~~~~+ + Definitionsphase + +~~~~~~~~~~~~~~~~~~+ LERNZIELE * Definitionsphase erklaeren koennen und ihre Rolle im Entwicklungsprozess definieren koennen * fuer vorgegebene Aufgabenstellungen ein Pflichtenheft entsprechend dem beschriebenen Pflichtenheftschema erstellen koennen * ein OO-Modell erstellen koennen EINFUEHRUNG * der iterative Prozess "Definieren des Produkts", welcher in der Definitionsphase ausgefuehrt wird, beinhaltet folgende Aktivitaeten + Anforderungen ermitteln und beschreiben + Anforderungen als fachliche Loesung modellieren + Anforderungen analysieren + Anforderungen animieren, simulieren und ausfuehren + Anforderungen verabschieden -> Ergebnis soll vollstaendiges, konsistentes und eindeutiges Produkt-Modell sein * Ueberblick ueber Definitionsphase + Akteure: Auftraggeber, Projektleiter, Anwendungsspezialist, Systemanalytiker + Eingabe: Muster-Pflichtenheft, Glossar, Lastenheft + Ausgabe: Produkt-Definition / -Spezifikation (erweitertes Glossar, Pflichtenheft, Produktmodell, Oberflaechenprototyp oder Pilotsystem, Benutzerhandbuch) * Dokumentation der Anforderungen + textuell/ graphisch, informal/formal - verbale Dokumenation in Form von Text, nummerierte Anforderungen, Gliederungsschema - weiter Dokumentationsformen: Pseudocode, Regeln, DD, Petrinetze (textuell), ET, Kollaborationsdiagramm, Zustandsdiagramm, Sequenzdiagramm, PAP, Struktogramm, Klassendiagramm, Entscheidungsbaeume, Datenflussdiagramm, ER, Petrinetze, Zustandsautomat * Pflichtenheft + Verfeinerung des Lastenheftes + mit Pflichtenheft und Glossar entsteht Produktmodell, welches Anforderungen konsistent, vollstaendig und eindeutig beschreibt + anhand des Produktmodells kann ein Oberflaechenprototyp erstellt werden, bei dem die Benutzungsoberflaeche ohne Funktionalitaet realisiert wird + schliesslich wird ein Benutzerhandbuch erstellt: Beschreibung der Handhabung und des Verhaltens des Systems * Gliederungsschema eines Pflichtenheftes (13 Punkte) + Zielbestimmung - Musskriterien (welche Ziele muessen erfuellt werden) - Wunschkriterien - Abgrenzungskriterien (welche Ziele sollen bewusst nicht erreicht werden) - welche Ziele sollen durch den Einsatz erreicht werden + Produkteinsatz - Anwendungsbereiche (z.B. Textverarbeitung im Buero, ...) - Zielgruppen (z.B. Sekretaerinnen, Schreibkraefte, ...) - Betriebsbedingungen (physikalische Umgebung, taegliche Betriebszeit, staendige Beobachtung durch Bediener, ...) + technische Produktumgebung - Software (Angabe von Software, die notwendig ist, z.B. Browser, ...) - Hardware (welche Hardware wird benoetigt, z.B. CD-Rom, ...) - Orgware (organisatorische Randbedingungen und Voraussetzungen, um Produkt sinnvoll einsetzen zu koennen) - Produktschnittstellen (Eingliederung in existierende Produktfamilie) + Produktfunktionen - Verfeinerung der Funktionen aus dem Lastenheft - verwenden von Geschaeftsprozess-Schablonen + Produktdaten - Verfeinerung der Daten aus dem Lastenheft - verbale oder formale Beschreibung - bei OOA werden Attribute in Klassen spezifiziert + Produktleistungen - Verfeinerung der Daten aus dem Lastenheft + Benutzungsoberflaeche - grundlegende Anforderungen an die Benutzungsoberflaeche, d.h. Fensterlayout, Mausbedienung etc. + Qualitaetsanforderungen - Qualitaetsmerkmale werden aufgelistet mit Qualitaetsstufe + nichtfunktionale Anforderungen - Beruecksichtigung von Gesetzen, Normen, Revisionsfaehigkeit, Plattformabhaengigkeiten etc. + globale Testszenarien - Testfall 1 - Testfall 2 + spezielle Anforderungen an die Entwicklungsumgebung + Ergaenzungen - z.B. Installationsbedingungen, Normen, Vorschrifte, Patente, Lizenzen + Anhang - Begriffslexikon / Glossar KLASSIFIKATION VON MODELLEN * Klassifizierung durch Abstraktionsgrad und Aspekt, nach dem modelliert wird + Abstraktion - Geschaeftsebene: - berechnungsunabhaengig - betrachtet Einsatzgebiet des Systems - betrachtet Gegenstaende und Akteure - betrachtet nur geschaeftliche Aspekte - betrachtet nicht das System selbst - Anforderungsebene: - plattformunabhaengig - Vermittlungsmodell, das Geschaeftsmodelle auf Realisierungen herunterbricht - Konzentration auf tatsaechliche Funktion - Realisierungsebene: - plattformabhaengig - Modell, das moeglichst unmittelbar in Software umgesetzt werden soll + Sichtweise - statisch-strukturell: zeigt, welche statischen Elemente es gibt und in welchen Beziehungen und Abhaengigkeiten sie zueinander stehen - dynamische Sicht: zeigt, wie sich Elemente verhalten, sich gegenseitig beeinflussen und / oder ihre Beziehungen zueinander aendern VERTIEFUNG DER KONZEPTE VON OBJEKTORIENTIERUNG UND UML * Definitionen + Menge G - Vereinigung aus allem vergangenen, gegenwaertigen und zukuenftigen Substanziellem und Konzeptuellem + Objekt - Ein fuer mindestens ein Individuum erkennbares, eindeutig von anderen Objekten unterscheidbares, also bestimmbares Element aus der Menge G + Menge Omega - Menge aller Objekte + Klasse - eine prinzipiell willkuerliche Kategorie ueber der Menge aller Objekte aus Omega - meist wird man der Kategorisierung eine Art von "Gleichartigkeit" zugrunde legen + Exemplar - ein konkretes Element aus einer bestimmten Klasse - a.k.a. Auspraegung - a.k.a. Instanz + Attribut - eine fuer alle Exemplare einer Klasse definiertes Vorhandensein einer Eigenschaft, die fuer jedes einzelne Exemplar unabhaengig von den anderen angegeben werden kann und einen klar definierten Wert aus einer bestimmten, fuer alle gleichen Domaene hat + Objektidentitaet - die Existenz eines Objektes ist unabhaengig von seinen Attributwerten - zwei Objekte sind auch dann unterscheidbar, wenn sie die gleichen Attributwerte besitzen + Gleichheit X. Stufe - 0. Stufe: es handelt sich um dasselbe Objekt, die Objekte sind identisch - 1. Stufe: es handelt sich entweder um dasselbe Objekt oder zwei verschiedene Objekte, die aber in allen Attributen identische Werte besitzen - 2. Stufe: es handelt sich entweder um dasselbe Objekt oder es handelt sich um zwei verschiedene Objekte, die aber in allen Attributen gleiche oder identische Werte besitzen - usw. + Zustand - solange sich ein Objekt in einem Zustand befindet, reagiert es im gleichen Kontext immer gleich auf seine Umwelt. Aendert sich der Zustand, reagiert das Objekt in mindestens einem Kontext anders als zuvor + Kapselungsprinzip - Zustand ist zwar nach aussen sichtbar, er wird aber im Inneren des Objektes verwaltet. + "Nachrichtenaustausch" - man moechte betonen, dass ein bestimmtes Objekt (Empfaenger) aufgefordert wird, einen Zustandsuebergang vorzunehmen - entspricht Methodenaufruf bei einem bestimmten Objekt + Methoden - aendern den Zustand eines Objektes - definieren die zulaessigen Botschaften, die man einem Objekt senden kann (Außenansicht) * Wo wird welcher Begriff verwendet + es gibt die Domaenen (1) Wirklichkeit (2) Modell und (3) objektorientierter Code + die Begriffe werden wie folgt verwendet - Entitaet (1,2) - Objekt (1,2,3) - Exemplar (1,2) - Klasse (2,3) - Instanz (2,3) - Typ (3) + Objekt wird v.a. in der Analysephase verwendet als Repraesentant einer Klasse + Klasse und Instanz wird auf Realisierungsebene verwendet, wenn Struktur der Klasse identifiziert und festgelegt ist * UML Diagramme + Assoziation wird zwischen Klassen angegeben und beschreibt moegliche Beziehung zwischen Exemplaren + Verknuepfung wird zwischen Exemplaren angegeben, druecken eine tatsaechliche Beziehung zwischen Exemplaren aus + Restriktionen bei Assoziationsenden: {ordered} und {unique} - Beispiele aus der Java-API: Collection (weder noch), Set (unique, nicht ordered), List (ordered, nicht unique), SortedSet (sowohl als auch) + spezielle Assoziationsformen - Aggregation: Teil-Ganzes-Beziehung (z.B. PKW hat Raeder) - Komposition: strenger, Teile haben keine Daseinsberechtigung ohne das Ganze (z.B. Rechnung besteht aus Rechnungsposten) - qualifizierte Assoziation: Assoziation, bei der die Menge der referenzierten Objekte durch einen Qualifizierer partitioniert ist (z.B. Bank, Kontonummer (Qualifizierer), Person) + Substitutionsprinzip - jedes Exemplar einer Unterklasse hat die gleichen Eigenschaften (Attribute, Assoziationen, Zusicherungen und Zustaende), die ein Exemplar der Oberklasse haette - es laesst sich genauso verwenden + Signatuervererbung vs. Implementierungsvererbung + Signaturvererbung - eine in der Oberklasse definierte und eventuell implementierte Methode uebertraegt nur ihre Signatur auf die Unterklasse + Implementierungsvererbung - eine in der Oberklasse definierte und implementierte Methode uebertraegt ihre Signatur und ihre Implementierung auf die Unterklasse + Ueberschreiben vs. Verfeinern vs. Ueberladen + Ueberschreiben - der Vorgang, eine geerbe Methode neu zu definieren (bezieht sich auf Syntax, also Signatur) + Verfeinern - der Vorgang, eine geerbte Methode neu zu implementieren (bezieht sich auf Semantik, also Implementierung) + Ueberladen - hat nichts mit Vererbung zu tun - neue Methode mit gleichem Namen aber anderer Signatur + Schnittstelle - Definition einer Menge abstrakter Methoden, die Klassen, die sie implementieren, anbieten muessen - gibt an, wie ein Objekt zu verwenden ist und nicht, was es darstellt + Parameter-Varianz - Varianz: Modifikation der Typen der Parameter einer ueberschriebenen Methode - Kovarianz: Verwendung einer Spezialisierung des Parametertyps in der ueberschriebenen Methode - Kontravarianz: Verwendung einer Verallgemeinerung des Parametertyps in der ueberschreibenden Methode - Invarianz: keine Modifikation des Typs - zulaessige Varianz bei ueberschreibenden Methoden (nicht alle zulaessing in Java oder C#): - Eingabeparameter (Kontravarianz) - Ausgabeparameter, auch Rueckgabewert und Ausnahmen (Kovarianz) - Ein-/Ausgabeparameter (Invarianz) + Zugriffsrechte - ("-") private: nur Exemplare derselben Klasse - ("#") protected: Exemplare derselben Klasse und aller abgeleiteten Klassen, sowie Exemplare aus dem gleichen Paket - ("+") public: jedes Exemplar + Zusicherung - Ausdruck, der die zulaessigen Auspraegungen, Inhalte oder Zustaende eines Modellelementes beschreibt und sich stets zu "wahr" auswerten lassen muss * Diagrammtypen + Anwendungsfalldiagramm (use case) - Anwendungsfall ist eine typische, gewollte Interaktion eines oder mehrerer Akteure mit einem System - ermoeglicht Kontrolle, ob System das vom Auftraggeber gewuenschte leistet - Hilfsmittel zur Anforderungsermittlung und -verwaltung, sie modellieren kein Verhalten und keine Ablaeufe! - beschreibt was ein System leisten muss, aber nicht wie! + Aktivitaetsdiagramm - beschreibt einen Ablauf - bestehen aus Aktions-, Objekt- und Kontrollknoten, sowie Objekt- und Kontrollfluessen - Partitionen beschreiben wer oder was fuer einen Knoten verantwortlich ist oder welche gemeinsame Eigenschaft sie kennzeichnet + Interaktionsdiagramme - zeigen die fuer einen bestimmten Zweck notwendigen Interaktionen zwischen Objekten - Klassendiagramm ist Grundlage - Kollaborationsdiagramme (Struktur der Interaktionspartner) - Zeitdiagramme (zeitliche Koordination) - Interaktionsuebersicht (Aktivitaetsdiagramme zur Veranschaulichung komplexer Sequenzdiagramme) - Sequenzdiagramme (Nachrichtenaustausch) - Nachrichtentypen: synchron (geschlossene Pfeilspitze). Antworten (gestrichelter Pfeil), asynchron (offene Pfeilspitze) - Operatoren: alt(ernativ), break, opt(ional), par(allel) + Zustandsdiagramm - beschreibt moegliche Zustaende eines Objektes soie moegliche Zustandsuebergaenge (endlicher Automat) - entry / aktion() und exit / aktion() beim Betreten bzw. Verlassen eines Zustandes - Zustandsautomat mit Hierarchisierung / mit Gedaechtnis / mit Nebenlaeufigkeit moeglich + Paketdiagramme - Ansammlung von Modellelementen beliebigen Typs - Gliederung des Gesamtmodells in ueberschaubare Einheiten - Abhaengigkeiten untereinander werden durch gestrichelte Pfeile dargestellt WIE KOMME ICH ZU EINEM GUTEN MODELL ? * Masterplan: + vier Schritte zum statischen Modell (1) Klassen identifizieren (2) Assoziationen identifizieren (3) Attribute identifizieren (4) Vererbungsstrukturen identifizieren + drei Schritte zum dynamischen Modell (5) Szenarien erstellen (6) Objektlebenszyklus erstellen (7) Operationen festlegen * Klassen finden + bottom-up - Attribute nehmen und zu Klassen zusammenfassen - durch scharfes Hinschauen Klassen identifizieren (z.B. reale Objekte in technischen Systemen) + top-down - Klassen aus Beschreibung der Geschaeftsprozesse identifizieren - syntaktische Analyse: Nomen-Verb-Analyse -> Substantive potenzielle Klasse (unterstreichen) - Inhaltliches Durchforsten nach Attributen, Akteuren, Verben (die Klassen sein koennen) - Probleme der linguistischen Analyse - Tilgung - Passivsaetze - Fremdwoerter - Dinge, die mehr als eine Klasse fordern - Fallunterscheidungen - Modalverben - Verzerrung zur Vereinfachung der Beschreibung - Nominalisierung (z.B. Ueberweisung -> ueberweisen) - Sinn-schwaches Verb plus Adjektiv (z.B. zu Ende sein) - Signalwoerter: ausser, allein, jedoch, wohingegen, indes, sondern, etc. - Quantoren: alle, immer, nie + wann liegt wohl keine Klasse vor? - keine Attribute und Operationen vorhanden - Klasse enthaelt Attribute etc. wie eine andere Klasse - enthaelt nur Operationen, die sich anderen Klassen zuordnen lassen - bei wenigen Attributen ueberpruefen, ob sich diese nicht anderen zuordnen lassen - Klasse modelliert Implementierungsdetails * Assoziationen finden + liegen zwischen Objekten dauerhafte Beziehungen vor? + was sagen die Verben aus? - raeumliche Naehe (wohnt in), Aktionen (faehrt), Kommunikation (redet mit), Besitz (hat), allgemeine Beziehung (verheiratet mit) + sind Klassen gleichrangig? - Assoziation, Aggregation pruefen - "ist Teil von" oder "besteht aus" ? + Informationsaustausch vorhanden? - uni- oder bidirektional + mehrere Assoziationen zwischen zwei Klassen vorhanden? + Kardinalitaeten pruefen - Muss-Beziehung, Kann-Beziehung, variable oder feste Grenzen + Rollennamen vergeben + Assoziation und Vererbung nicht verwechseln * Attribute finden + Ist Attribut im Sinne der Systemanalyse problemrelevant? + Blickwinkel / Abstraktionsniveau - sind Datenstrukturen fuer die Attribute gebildet - Wiedergabe eines Abstraktionsniveau, nicht mehrerer + gehoert Attribut zur Klasse oder zur Assoziation - bei der isolierten Betrachtung einer Klasse: muss das Attribut immer noch zu jedem Objekt der Klasse gehoeren? - ja: dann gehoert es zur Klasse - nein: dann gehoert es wohl zu einer Assoziation - sonst: vermutlich wurde Klasse vergessen + Spezifikation - Name (Substantiv, oder Adjektiv-Substantiv-Kombination) - Domaene (besser allgemeiner als zu speziell) - Anfangswert - Restriktion - Klassenattribut - abgeleitetes Attribut - Muss-Attribut - Schluessel - aenderbar nach erstmaligem Eingeben - Beschreibung * Erstellen von Vererbungsstrukturen + Substitutionsprinzip muss gelten - mache eine Klasse B erst zur Unterklasse einer Klasse A, wenn gezeigt werden kann, dass jedes Exemplar von B auch als ein Exemplar von A gesehen werden kann + bottom-up: von spezialisierten zu den allgemeineren Klassen + top-down: von den allgemeineren Klassen ausgehend spezialisierte Klassen suchen + liegt Mehrfachvererbung vor ? + Sub1 und Sub2 Unterklassen von Super - notwendig, Sub1 und Sub2 zu unterscheiden - beide besitzen zusaetzliche disjunkte Eigenschaften - Ist-Ein-Beziehung zwischen Super und Sub1/Sub2 * Szenarien erstellen + von Anwendungsfaellen zu Sequenz- und Kollaborationsdiagramme - Aufgaben in Operationen aufteilen - sind Empfaenger vorhanden (Assoziationen) ? - existieren alle Klassen / Operationen ? * Objektlebenszyklus erstellen + Ergebnis: Zustandsautomat einer Klasse - nicht-triviale von trivialen Lebenszyklen trennen (wenn also zwischen Initialisierung und Destruktion nur ein einziger Zustand existiert) - notwendig, wenn ein gleiches Ereignis unterschiedliche Aktionen ausloesen kann (je nach Zustand) - notwendig, wenn Operationen nur in manchen Situationen angewendet werden koennen * Operationen festlegen + Zuordnung von Operationen zu Klassen ueberpruefen + Konstruktoren immer in jeweiliger Klasse, ausser bei Komposition: dann in Aggregatklasse + jede Operation sollte genau eine Funktion erfuellen * Subsysteme bilden + Bildung von Paketen oder Subsystemen - innerhalb des Subsystems starke Kohaesion - ausserhalb schwache Kopplung zwischen den Subsystemen + bottom-up: welche Klassen gehoeren logisch zueinander + top-down: Zerlegung des Gesamtsystems in Subsysteme +~~~~~~~~~~~~~~~+ + Entwurfsphase + +~~~~~~~~~~~~~~~+ EINFUEHRUNG UND UEBERBLICK * Aufgabe der Entwurfsphase + Eingabe sind die Anforderungen aus der Definitionsphase + Ausgabe: entwickle software-technische Loesung im Sinne einer Softwarearchitektur - Gliederung eines Softwaresystems in Komponenten (Module, Klassen) und Subsysteme (Pakete, Bibliotheken) - Beschreibung der Funktion und Schnittstellen der Komponenten - Beschreibung der Beziehung zwischen Komponenten - optional: Feinentwurf (Datenstrukturen, Algorithmen, Pseudocode) + Entwerfen ist das "Programmieren im Großen" - bisher: "was bauen wir?", jetzt "wie strukturieren wir es?" * Einflussfaktoren + Einsatzbedingungen - aus den Produktanforderungen - sequentiell, parallel (nebenlaeufig, verteilt), Echtzeit, Anzahl Benutzer, ... + Umgebungsbedingungen - aus der verwendeten Zielplattform + Randbedingungen - nichtfunktionale Produktanforderungen - Qualitaetsanforderungen - unterschiedliche Landessprachen, Waehrungen, MWST, verschiedene Plattformen, Leistungsanforderungen MODULARER ENTWURF * Vorgehensweise + zunaechst externer Entwurf (Grobentwurf und Modulschnittstellen), danach interner Entwurf (Benutztrelation und Feinentwurf) + Grobentwurf / Modulfuehrer - Gliederung in Komponenten / Module und Subsysteme - Beschreibung der Funktion der Module - nutzt Schichtenarchitektur oder Fliessbandarchitektur (Entwurfsmuster) + Modulschnittstellen - genaue Beschreibung der von jedem Modul zur Verfuegung gestellten Komponenten (Typen, Var, etc.) - auch von Ein- / Ausgabe genaue Beschreibung + Benutztrelation - beschreibt, wie sich Module und Subsysteme untereinander nutzen - sollte azyklischer, gerichteter Graph sein + (optional) Feinentwurf - Beschreibung der modulinternen Datenstrukturen - oft mit Pseudocode * Anforderungen + Module sollten unabhaengig voneinander bearbeitet und benutzt werden koennen - Implementierung sollte moeglich sein, ohne etwas ueber Interna anderer Module wissen zu muessen - sollte ohne Kenntnis der spaeteren Nutzung entworfen, implementiert, getestet und ueberarbeitet werden koennen - Kapselung der inneren Struktur - Modul enthaelt Unterprogramme, die eine Datenstruktur manipulieren - starke Kohaesion innerhalb des Modules, ausserhalb weniger * Definition + Modul - Ein Modul ist eine Menge von Programmkomponenten, die nach dem Geheimnisprinzip gemeinsam entworfen und geaendert werden + Geheimnisprinzip - Jedes Modul verbirgt eine wichtige Entwurfsentscheidung hinter einer wohldefinierten Schnittstelle, die sich bei einer Aenderung der Entscheidung nicht mit aendert. + Vorgehensweise: - bilde Liste von Entscheidungen, die schwierig sind oder die sich voraussichtlich aendern werden - weise jeder Entscheidung ein Modul zu und definiere die Schnittstelle so, dass sie sich bei einer Aenderung der Entscheidung nicht mitaendert - Beispiele: Implementierung von ADTs, maschinennahe Details, OS Details, Datenbanken, E/A-Formate, Benutzungsschnittstelle, Text von Dialogen etc, ... * Modulfuehrer + Ergebnis: Grobentwurf - beschreibt jedes Modul und Subsystem - liefert Zerlegung des Problems - erleichtert Auffinden von betroffenen Modulen * Modulschnittstellen + Ergebnis: Beschreibung der Module ("black box") - enthaelt genau die Informationen, die fuer die Benutzung als auch fuer die Implementierung wichtig sind - invariant gegenueber etwaigen Aenderungen in der Zukunft - sollte liefern: Eingabe, Ausgabe, Parameter und Rueckgabewerte der Unterprogramme, Effekte, Fehlerbeschreibung, Fehlerverhalten, Ausnahmen, etc. * Modul in Programmiersprachen + Programmiersprachen liefern Ausdrucksmittel + Zerlegung eines Moduls in Definitionseinheit und Implementierungseinheit (gleichen Namens) - Definitionseinheit liefert externe Schnittstelle - Implementierungseinheit enthaelt privaten Datenstrukturen und Typen, Modulinterna, ... - zu jeder Definitionseinheit gibt es hoechstens eine Implementierungseinheit - nur ein Exemplar eines Moduls moeglich (Ausweg: kopieren und umbennen) - i.G. dazu OOP, wo Schnittstellen von verschiedenen Klassen implementiert werden koennen, davon mehrere Objekte erzeugt werden koennen + Zerlegung (top-down, bottom-up, middle-out) * Benutztrelation + Programmkomponente A benutzt Komponente B gdw. A fuer den korrekten Ablauf die Verfuegbarkeit einer korrekten Implementierung von B erfordert + verschiedene Hierarchie-Relationen - delegiert-an - ist-ein - hat-ein - enthaelt-ein - greift-zu-auf - ist-privilegiert-zu - ruft auf - aufgerufen-von - benutzt - stellt-Betriebsmittel-bereit + Benutzthierarchie liegt vor, wenn die Benutztrelation zyklenfrei ist + wann soll A B benutzen ? - A wird einfacher durch Benutzung von B - B wird nicht wesentlich komplexer dadurch, dass es A nicht verwenden darf - es existiert nuetzliche Untermenge, die B, aber nicht A enthaelt - es gibt keine Untermenge, die A, aber nicht B enthaelt + Aufloesung von zyklischer Benutzung durch Sandwiching (Verfeinerung der Modulstruktur) - Beispiel: A nutzt B1, B2 nutzt A und B1 -> A verfeinern in A1 und A2, A1 nutzt B1, B2 nutzt A1 und B1, A2 nutzt B2 und A1 * abstrakte / virtuelle Maschine + ist eine Menge von Software-Befehlen und -objekten, die auf einer darunterliegenden Maschine aufbauen und diese ganz oder teilweise verdecken koennen + Beispiele: OS, JVM, System zur Bearbeitung elektronischer Post, Makros * Programmfamilie / Software-Produktlinie + ist eine Menge von Programmen, die erhebliche Anteile von Anforderungen, Entwurfsbestandteilen oder Software-Komponenten gemeinsam haben - neue Mitglieder der Produktlinie koennen somit rasch entwickelt werden - man muss nicht bei Null beginnen - externe Unterscheidungen: verschiedene Hardware/Betriebssystem-Konfigurationen, E/A-Formate, Funktionsumfang - interne Unterscheidungen: Datenstrukturen, Algorithmen OBJEKTORIENTIERTER ENTWURF * Prinzipien des modularen Entwurfs behalten Gueltigkeit + neu sind v.a. Schnittstellen, die Entwurfsentscheidungen verbergen und veraenderbar bleiben + externer Entwurf - anstatt Module werden Pakete / Klassen verwendet - in der Regel mehrere Klassen pro Modul - anstelle des Modulfuehrers tritt der Paket- und Klassenfuehrer -> UML Diagramme - analog zu Modulschnittstellen treten nun Schnittstellen der Klassen, abstrakten Klassen und reinen Schnittstellen (interfaces) auf + interner Entwurf - Benutztrelation zwischen Paketen und alleinstehenden Klassen wird dokumentiert - Feinentwurf liefert Beschreibung der modulinternen Datenstrukturen und Algorithmen + neue Moeglichkeiten im OO-Entwurf - Mehrfachinstanziierung von Klassen - Vererbung - Polymorphie - Variantenbildung durch Mehrfachimplementierung einer Schnittstelle -> Entwurfsmuster ENTWURFSMUSTER * beschreibt Famile von Loesung eines Softwareproblems + Ziel: Wiederverwendung eines Entwurfsmusters + Entwurfsmuster sind das fuer den Entwurf, was Algorithmen fuer das "Programmieren im Kleinen" sind * Entwurfsmuster Kategorien + Entkopplungs-Muster - teile ein System in mehrere Einheiten, sodass einzelne Einheiten unabhaengig voneinander erstellt, veraendert und wiederverwendet werden koennen - meist liegt ein Entkopplungsglied vor, das die Einheiten miteinander kommunizieren laesst - Beobachter - abstrakter Datentyp - Modul - Datenablage - Iterator - Schichtenarchitektur - Vermittler - Bruecke - Adapter - Stellvertreter - Fliessband - Ereigniskanal - Rahmenarchitektur + Varianten-Muster - Gemeinsamkeiten von verwandten Einheiten werden herausgezogen und an einer einzigen Stelle beschrieben - unterschiedliche Komponenten koennen aufgrund ihrer Gemeinsamkeiten einheitlich verwendet werden - Wiederholungen desselben Codes werden vermieden - Oberklasse - Kompositum - Strategie - Besucher - Schablonenmethode - Fabrikmethode - Erbauer - abstrakte Fabrik + Zustandhandhabungs-Muster - bearbeiten den Zustand eines Musters, unabhaengig von deren Zweck - Memento - Prototyp - Fliegengewicht - Einzelstueck + Steuerungs-Muster - steuern den Kontrollfluss - zur richtigen Zeit werden die richtigen Methoden aufgerufen - Tafel - Befehl - Zustaendigkeitskette - Master/Slave - Prozesssteuerung + virtuelle Maschinen - erhalten Daten und ein Programm als Eingabe und fuehren das Programm selbstaendig an den Daten aus - implementiert in Software - Interpretierer - regelbasierter Interpretierer + Bequemlichkeits-Muster - Bequemlichkeitsmethode - Bequemlichkeitsklasse - Fassade - Nullobjekt ENTKOPPLUNGSMUSTER * Observer / Beobachter + Subjekt (Modell) und Beobachter (Sichten) + definiert eine 1-zu-n Abhaengigkeit zwischen Objekten, so dass die Aenderung eines Zustand eines Objektes dazu fuehrt, dass alle abhaengigen Objekte benachrichtigt und automatisch aktualisiert werden * Abstract Datatype / Abstrakter Datentyp + definiert neuen Datentyp zusammen mit geeigneten Operationen - Implementierung ist wie beim Modul hinter einer Schnittstelle verborgen - keine Vererbung/Polymorphie, im Gegensatz zum Modul koennen mehrere Exemplare erzeugt werden, Modul meist groessere Einheit * Module / Modul + s.o. * Repository / Datenablage + Menge unabhaengiger Komponenten kommunizieren ueber eine zentrale Ablage, in dem sie Elemente in dieser Datenstruktur ablegen oder aus ihr entfernen - Beispiele: Datenbanken, Hypertextsysteme, Linda * Iterator + ermoeglicht den sequentiellen Zugriff auf die Elemente eines zusammengesetzten Objekts, ohne seine zugrundeliegende Repraesentation offenzulegen - Komponenten sind Aggregat (abstrakt), Iterator (abstrakt), KonkretesAggregat und KonkreterIterator - Zugriff auf den Inhalt eines zusammengesetzten Objekts ermoeglicht - mehrere Traversierungen moeglich - einheitliche Schnittstelle zur Traversierung * layered architecture / Schichtenarchitektur + gliedere System in eine hierarchische geordnete Menge von Schichten + Schicht besteht aus Menge von Softwarekomponenten mit einer wohlfundierten Schnittstelle, nutzt die darunterliegenden Schichten als Klient und stellt seine Dienste an darueberliegende Schichten zur Verfuegung - es muss ein natuerliches Abstraktionskriterium geben - geeignete Granularitaet fuer die einzelnen Schichten - Strukturierungsformen: linear, strikt, baumartig, ... - Vorteile - uebersichtliche Strukturierung - strenge Hierarchie aber dennoch genug Moeglichkeiten innerhalb der Schicht - Wiederverwendbarkeit, Aenderbarkeit, Wartbarkeit, Portabilitaet und Testbarkeit unterstuetzt - Nachteile - Effizienzverlust (Daten muessen ueber verschiedene Schichten transportiert werden) - Einteilung in Schichten nicht immer moeglich - Chaos innerhalb der Schicht moeglich - Beispiel: Mikrokerne, Protokolltuerme, Informationssysteme (Datenbanken aufbauend) * Mediator / Vermittler + definiere Objekt, welches das Zusammenspiel einer Menge von Objekten in sich kapselt + foerdert lose Kopplung, indem sie verhindern, dass Objekte explizit aufeinander Bezug nehmen + Komponenten: Vermittler (abstrakt), Kollege (abstrakt), KonkreterVermittler, KonkreterKollege1, KonkreterKollege2 - Beispiele: Button und Knopf (GUI) * Bridge / Bruecke + entkopple eine Abstraktion von ihrer Implementierung, so dass beide unabhaengig voneinander variiert werden koennen + Komponenten: Abstraktion (abstrakt), Implementierer (abstrakt), SpezialisierteAbstraktion, KonkreterImplementiererA, KonkreterImplementiererB - Beispiel: Fenster, XFenster, PMFenster -> IconFenster hinzufuegen - anwendbar, wenn sowohl Abstraktion als auch Implementierung durch Unterklassenbildung erweiterbar sein sollen - wenn starke Vergroesserung der Anzahl der Klassen vermieden werden soll * Adapter + passe die Schnittstelle einer Klasse an eine andere von ihren Klienten erwartete Schnittstelle + Klassen koennen zusammenarbeiten, die wegen inkompatibler Schnittstellen sonst nicht in der Lage dazu waeren + Objektadapter (ohne Mehrfachvererbung): Klient, Ziel (abstrakt), Adapter, AdaptierteKlasse + Klassenadapter (mit Mehrfachvererbung): dito * Proxy / Stellvertreter + kontrolliere Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts + Komponenten: Klient, Subjekt (abstrakt), EchtesSubjekt, Stellvertreter - anwendbar, sobald es den Bedarf nach einer anpassungsfaehigeren und intelligenteren Referenz auf ein Objekt als einen einfachen Zeiger gibt - Beispiele - protokollierender Stellvertreter (zaehlt Referenzen auf Objekt, loescht es, wenn keine mehr da) - puffernder Stellvertreter (laedt ein Objekt erst in Speicher, wenn es angesprochen wird zum ersten Mal) - Fensterzugriffsvertreter (stellt Vertreter fuer Objekt in anderem Adressraum dar) - Platzhalter (erzeugt teure Objekte auf Verlangen) - Schutzwand (kontrolliert Zugriff auf eigtl Objekt) - Dekorierer (fuegt zusaetzliche Zustaendigkeiten zu einem bestehenden Objekt hinzu) * Pipeline / Fliessband + bietet eine Struktur fuer Systeme, die Datenstroeme bearbeiten + jeder Bearbeitungsschritt ist in einer Filterkomponente gekapselt + Daten wandern von einem Filter zum naechsten Filter - Beispiel: Uebersetzer, Compiler - schlecht fuer interaktive Systeme * Event Channel / Ereigniskanal + entkopple Teilnehmer an einem Gesamtsystem vollstaendig voneinander, so dass sie voellig eigenstaendig arbeiten koennen und ueber die Existenz oder Anzahl anderer Teilnehmer nichts wissen + Interaktionen erfolgen ueber Ereignisse - Beispiel: IDE, speichern fuehrt zum Starten des Uebersetzers und zur Aktualisierung der Anzeige * Framework / Rahmenarchitektur + biete nahezu vollstaendiges Programm, welches an bestimmten Stellen erweitert werden kann / soll + die Anwendungslogik ist vorgegeben, meist auch das Hauptprogramm + Rahmenprogramm sieht vor, dass die vom Benutzer gelieferten Erweiterungen richtig aufgerufen werden + Plugins sind solche Erweiterungen - Beispiel: Eclipse - anwendbar wenn Grundversion einer Anwendung schon funktionstuechtig ist, wenn Erweiterungen moeglich sein sollen, die sich konsistent verhalten oder wenn komplexe Anwendungslogik nicht neu programmiert werden soll - Strategie, Fabrikmethode, abstrakte Fabrik und Schablonenmethode werden haeufig benoetigt VARIANTENMUSTER * Super Class / Oberklasse + einheitliche Behandlung von Objekten, die unterschiedlichen Klassen angehoeren, aber gemeinsame Attribute oder Methoden nutzen * Composite / Kompositum + fuege Objekte zu Baumstruktur zusammen, um Bestandshierarchie aufzubauen * Strategy / Strategie + definiere Familie von Algorithmen, kapsele sie und mache sie austauschbar + Algorithmus kann nun variiert werden * Visitor / Besucher + kapsle eine auf den Elementen einer Objektstruktur auszufuehrende Operation als ein Objekt + ermoeglicht eine neue Operation zu definieren, ohne die Klassen der von ihr bearbeiteten Elemente zu veraendern - Anwendbarkeit - wenn Objektstruktur viele Klassen von Objekten mit unterschiedlichen Schnittstellen enthaelt und Operationen auf diesen Objekten ausgefuehrt werden sollen, die von ihren konkreten Klassen abhaengen - wenn viele unterschiedliche und nicht miteinander verwandte Operationen auf den Objekten einer Objektstruktur ausgefuehrt werden muessen und diese Klassen nicht mit diesen Operationen verschmutzt werden sollen - wenn sich die Klassen, die eine Objektstruktur definieren, praktisch nie aendern, aber haeufig neue Operationen fuer die Struktur definiert werden * Template Method / Schablonenmethode + definiere Skelett eines Algorithmus in einer Operation und delegiere einzelne Schritte an Unterklasse + ermoeglicht es Unterklassen, bestimmte Schritte eines Algorithmus zu ueberschreiben, ohne seine Struktur zu aendern * Factory Method / Fabrikmethode + definiere eine Klassenschnittstelle mit Operationen zum Erzeugen eines Objekts, aber lasse Unterklassen entscheiden, von welcher Klasse das zu erzeugende Objekt ist + ermoeglicht es einer Klasse, die Erzeugung von Objekten an Unterklassen zu delegieren - Anwendbarkeit - wenn Klasse die Klasse von Objekten, die sie erzeugen muss, nicht im voraus kennen kann - wenn Klasse moechte, dass Unterklasse die von ihr zu erzeugenden Objekte festlegt - wenn Klassen Zustaendigkeiten an eine von mehreren Hilfsunterklassen delegieren sollen * Builder / Erbauer + trenne die Konstruktion eines komplexen Objekts (bestehend aus mehreren Teilen) von seiner Repraesentation, so dass derselbe Konstruktionsprozess unterschiedliche Repraesentationen erzeugen kann - Anwendbarkeit - Algorithmus zum Erzeugen eines komplexen Objekts soll unabhaengig von den Teilen sein, aus denen das Objekt besteht und wie sie zusammengesetzt werden - Konstruktionsprozess muss verschiedene Repraesentationen des zu konstruierenden Objekts erlauben * Abstract Factory / Abstrakte Fabrik + bietet eine Schnittstelle zum Erzeugen von Familien verwandter oder voneinander abhaengiger Objekte, ohne ihre konkreten Klassen zu benennen - Anwendbarkeit - wenn System unabhaengig davon sein soll, wie seine Produkte erzeugt, zusammengesetzt und repraesentiert werden - wenn System mit einer von mehreren Produktfamilien konfiguriert werden soll - bei einer Klassenbibliothek, die nur die Schnittstellen, nicht aber die Implementierungen offen legt ZUSTANDHANDHABUNGSMUSTER * Memento + erfasse und externalisiere den internen Zustand eines Objekts, ohne seine Kapselung zu verletzen, so dass das Objekt spaeter in diesen Zustand zurueckversetzt werden kann - Beispiele: Undo-Mechanismen, Haltepunkte - Anwendbarkeit - wenn Momentaufnahme (eines Teils) des Zustands eines Objekts zwischengespeichert werden muss, so dass es zu einem spaeteren Zeitpunkt in diesen Zustand zurueckversetzt werden kann und - wenn eine direkte Schnittstelle zum Ermitteln des Zustands die Implementierungsdetails offenlegen und die Kapselung des Objekts aufbrechen wuerde * Prototype / Prototyp + bestimme die Arten zu erzeugender Objekte durch die Verwendung eines typischen Exemplars und erzeuge neue Objekte durch Kopieren dieses Prototyps - Anwendbarkeit - wenn System unabhaengig davon sein soll, wie seine Produkte erzeugt, zusammengesetzt und repraesentiert werden - falls Aufbau wesentlich mehr Zeit kostet als Kopieren eines Prototyps - wenn Klassen zum Erzeugen erst zur Laufzeit spezifiziert werden * Flyweight / Fliegengewicht + nutze Objekte kleinster Granularitaet gemeinsam, um große Mengen von ihnen effizient speichern zu koennen - Anwendbarkeit - Anwendung verwendet grosse Menge von Objekten - wenn Speicherkosten hoch sind - wenn Grossteil des Objektzustands in den Kontext verlagert und damit extrinsisch gemacht werden kann * Singleton / Einzelstueck + Klasse hat genau ein Exemplar mit globalem Zugriffspunkt STEUERUNGSMUSTER * Blackboard / Tafel + nuetzlich bei Problemen, fuer die keine deterministischen Loesungsstrategien bekannt sind + mehrere spezialisierte Subsysteme vereinigen ihr Wissen auf der Tafel um eine eventuell partielle oder approximative Loesung zu finden - Beispiel: Spracherkennung (Kontrolle aktiviert Wissensquelle der Reihe nach oder bestimmt Reihenfolge) - Anwendbarkeit - wenn mehrere Transformationen auf einer gemeinsamen Datenstruktur arbeiten - wenn Auswahl der Transformationen gesteuert werden soll * Command / Befehl + kapsle einen Befehl als ein Objekt + ermoeglicht Klienten mit verschiedenen Anfragen zu parametrisieren, Operationen in eine Warteschlange zu stellen, ein Logbuch zu fuehren und Operationen rueckgaengig zu machen - Anwendbarkeit - wenn Objekte mit einer auszufuehrenden Aktion parametrisiert werden sollen - wenn Anfragen zu unterschiedlichen Zeiten spezifiziert, aufgereiht und ausgefuehrt werden sollen - wenn Rueckgaengigmachen / Logging unterstuetzt werden soll - wenn System mittels komplexer Operationen, die aus primitiven Operationen bestehen strukturiert werden soll * Chain of Responsibility / Zustaendigkeitskette + vermeidet die Kopplung des Ausloesers einer Anfrage mit seinem Empfaenger, indem mehr als ein Objekt die Moeglichkeit erhaelt, die Anfrage zu erledigen + verkettet die empfangenden Objekte und leitet die Anfrage an der Kette entlang, bis ein Objekt sie erledigt - Anwendbarkeit - wenn mehr als ein Objekt eine Anfrage bearbeiten koennen soll und das Objekt zur Laufzeit nicht bekannt ist - wenn Anfrage an eines von mehreren Objekten gerichtet werden soll, ohne den Empfaenger explizit anzugeben - wenn Menge von Objekten, die Anfrage bearbeiten soll, dynamisch festgelegt wird * Master-Slave + unterstuetzt Fehlertoleranz und parallele Berechnung + Masterkomponente verteilt die Arbeit an identische Slavekomponenten und berechnet Ergebnis aus den Teilergebnissen - Anwendbarkeit - wenn es mehrere Aufgaben gibt, die unabhaengig voneinander bearbeitet werden koennen - wenn mehrere Prozessoeren zur parallelen Verarbeitung zur Verfuegung stehen - wenn die Belastung der Arbeitet ausgeglichen werden soll * Process Control / Prozesssteuerung + reguliert einen physikalischen (kontinuierlichen) Prozess + Varianten - System ohne Rueckkopplung - System mit Rueckkopplung - Regelung mit Rueckfuehrung - Regelung mit Stoergroessenaufschaltung VIRTUELLE MASCHINEN * Interpreter / Interpretierer + definiere fuer eine gegebene Sprache eine Repraesentation der Grammatik sowie einen Interpretierer, der die Repraesentation nutzt, um Saetze in der Sprache zu interpretieren - Anwendbarkeit - Ausdruecke der Sprache als abstrakte Syntaxbaeume - Grammatik ist einfach - Effizienz sollte unproblematisch sein - Spezialfall des Kompositums * Rule-based Systems / Regelbasierter Interpretierer + loese ein Problem durch Anwendung einer Menge von Regeln + Regel besteht aus Bedingungsteil und Aktionsteil + Aktionsteil aendert, ersetzt oder loescht Datenelemente, die im Bedingungsteil ausgewaehlt wurden oder fuegt neue hinzu - Anwendbarkeit - wenn Problemloesung am besten als Menge von Bedingungs-Aktions-Regeln formuliert werden kann - wenn Aktionsteil nur einfache Operationen an den Datenelementen erfordert BEQUEMLICHKEITSMUSTER * Convenience Method / Bequemlichkeitsmethode + vereinfachen des Methodenaufrufs durch die Bereitstellung haeufig genutzter Parameterkombinationen in zusaetzlichen Methoden (Ueberladen) - wenn Methodenaufrufe haeufig mit den gleichen Parametern auftreten * Convenience Class / Bequemlichkeitsklasse + vereinfache Methodenaufruf durch Bereithaltung der Parameter in einer speziellen Klasse - wenn Methoden haeufig mit den gleichen Parametern aufgerufen werden, die sich nur selten aendern * Facade / Fassade + biete einheitliche Schnittstelle zu einer Menge von Schnittstellen eines Subsystems + Fassadenklasse definiert eine abstrakte Schnittstelle, welche die Benutzung des Subsystems vereinfacht - Anwendbarkeit - wenn einfache Schnittstelle zu einem komplexen Subsystem angeboten werden soll - wenn es viele Abhaengigkeiten zwischen den Klienten und den Implementierungsklassen einer Abstraktion gibt - wenn Subsysteme in Schichten aufgeteilt werden sollen; man verwendet Fassade, um einen Eintrittspunkt zu jeder Subsystemschicht zu definieren * Null objekt / Nullobjekt + stelle einen Stellvertreter zur Verfuegung, der die gleiche Schnittstelle bietet, aber nichts tut +~~~~~~~~~~~~~~~~~~~~~~~+ + IMPLEMENTIERUNGSPHASE + +~~~~~~~~~~~~~~~~~~~~~~~+ EINFUEHRUNG UND UEBERBLICK * In der Implementierungsphase geschieht die Programmierung, Dokumentierung und Testen der Systemkomponenten aufgrund vorgegebener Spezifikationen der Systemkomponenten + Voraussetzungen - Softwarearchitektur aus der Entwurfsphase (modularer oder objektorientierter Entwurf) - fuer jede Systemkomponente existiert eine Spezifikation * was wird genau gemacht + Konzeption von Datenstrukturen und Algorithmen + Strukturierung durch Verfeinerungsebenen + Dokumentation der Problemloesungen und Implementierungsentscheidungen + Umsetzung in die Programmiersprache + Angabe von Zeit- und Speicherkomplexitaeten + eventuelle Programmoptimierungen + Test / Verifikation des Programms einschliesslich Testplanung und Testfallerstellung -> "Programmieren im Kleinen" -> es entstehen Quellprogramme einschliesslich Dokumentation, Objektprogramme und ausfuehrbare Testfaelle, die spaeter integriert und getestet werden muessen ABBILDUNG VON UML-MODELLE AUF CODE * Abbildung von Klassen + in objektorientierten Sprachen wird aus UML Klasse eine objektorientierte Klasse + in nicht-objektorientierten Sprachen - Attribute werden in Verbund gespeichert - Methoden werden auf Unterprogramme abgebildet mit Verbundtyp als Referenzparameter - Vererbung wird dadurch realisiert, dass dem Verbund die Attribute der Oberklasse hinzugefuegt werden - Polymorphie durch Funktionszeiger und Typumwandlungen * Abbildungen von Assoziationen + alle Sprachen besitzen keine Assoziationen, nur Referenzen + nutze diese um verschiedenste Assoziationsarten zu ermoeglichen * Abbildung von Zustandsautomaten + implizite Speicherung - Zustand kann implizit aus Attributwerten berechnet werden - keine dedizierten Instanzvariablen notwendig - muss jedes Mal neu berechnet werden - Zustandsuebergangsfunktion ist ebenfalls implizit + explizite Speicherung - Zustand eines Objekts wird in dedizierten Instanzvariablen gespeichert - einfaches Auslesen moeglich - dafuer mehr Speicher notwendig - Zustandsuebergangsfunktion muss explizit sein + Alternativen der Implementierung expliziter Speicherung der Zustaende + eingebettet - jede Methode kennt den kompletten Automaten - Aufgabe entsprechend aktuellem Zustand - nimmt Verwaltung der Zustaende selbst vor - kompakt, schnell + ausgelagert - Methode fragt aktuellen Zustand, was zu tun ist - Code zur Verwaltung der Zustaende befindet sich in dedizierten Klassen - flexibler, bei großen Automaten uebersichtlicher PROGRAMMOPTIMIERUNGEN * Laufzeitreduktion (Lx = Leistungsoptimierung x) + Optimierungsebenen - Problemstellung - Systemstruktur - Algorithmen und Datenstrukturen - Feinoptimierung - Systemsoftware - Hardware + finde Zeitfresser mittels Laufzeitprofilierer und optimiere nur diese + L1: vereinfache Problemstellung + L2: Systemstruktur optimieren, nutze Ueberschlagsrechnung, um die Leistung eines geplanten Systems abzuschaetzen! + Algorithmen und Datenstrukturen verbessern - L3: Speicherung von Zwischenergebnissen statt Neuberechnung - L4: Vorverarbeitung der Daten - L5: Teile und Herrsche - L6: Dynamisches Programmieren + Feinoptimierung / Code Tuning - verbessern der Laufzeit, ohne asymptotische Laufzeit zu aendern, sprich: Verbesserung um Konstante - L7: Ausnutzung eines haeufig auftretenden Falles - L8: Vorausberechnung einer logischen Funktion - L9: Ausnutzung algebraischer Identitaeten - L10: Erweiterung von Datenstrukturen um Waechterelemente - L11: Ausrollen von Schleifen - L12: kombinieren von Schleifen ueber denselben Bereich (loop jamming) - L13: Entfernung invarianter Ausdruecke aus Schleifen - L14: Rekursionseliminierung - Funktion ist rechtsrekursiv oder restrekursiv, falls sie entweder ihren Wert direkt berechnet oder ihr Wert das unveraenderte Ergebnis eines rekursiven Aufrufs ist - oft laesst sich eine rechtsrekursive Funktion durch eine Hilfsfunktion finden - siehe Beispiele in den Foliensaetzen + benutze Systemsoftware - L15: wechseln von Interpretierer zu Compiler (Beispiel: anstatt PHP ein C Programm schreiben) - L16: Uebersetzungsoptimierung - L17: Betriebssystem-Auswahl, am besten Linux statt Windows :D - L18: Datenbankauswahl, -anpassung - L19: Neuimplementierung von Bibliotheksroutinen + Hardware - L20: Spezialhardware - L21: Fliessbandverarbeitung / Pipelining - L22: Multiprozessoren, Cluster * Speicherplatzreduktion (Sx = Speicherplatzoptimierung x) + reduziere sowohl Datenraum als auch Programmraum + Datenraum - S1: Neuberechnen statt Speichern - S2: Kompression von spaerlichen Datenstrukturen - S3: speichere grosse, identische Datenobjekte nur einmal - S4: Datenkompression - S5: dynamische Speicherplatzvergabe - S6: Saetze variabler Laenge nutzen - S7: gemeinsame Nutzung von Speicherplatz (Beispiel: Stack und Heap) + Programmraum - S8: ersetze wiederholte Anweisungen durch Unterprogramme - S9: Minisprachen und Spezialinterpretierer fuer kompakte Darstellung - S10: Assembler-Codierung * Cache-Optimierungen + komprimiere Daten, damit moeglichst viele Elemente gleichzeitig im Cache liegen + sequentieller statt wahlfreier Zugriff + vermeide verzeigerte Datenstrukturen (Baum besser als Feld implementieren) + cache-bewusste Allokation - verkettete Elemente hintereinander anlegen - cache-bewusste Baumorganisation PROGRAMMIERRICHTLINIEN * you should really know this... + konsistenter Stil erleichtert Lesbarkeit + beschleunigt Einarbeitung bei Personalwechsel + Zeitersparnis bei Fehlerfindung, Erweiterung und Pflege + muss konsistent angewendet werden + nicht uebertreiben, immer mit Augenmaßanwenden * Formatierung + Leerzeichen erleichtern Lesbarkeit + Stile - K&R Style / Unix Kernel style if (cond) { foobar } - Allman style / BSD style if (cond) { foobar } - Whitesmiths style if (cond) { foobar } - GNU style if (cond) { foobar } * Namenskonventionen + Zahl der Funktionen wird bei groesseren Systemen unuebersichtlich + Name soll an Zweck erinnern + Prinzip der Verbalisierung - natuerlichsprachliche und problemnahe Bezeichner - Grossbuchstaben oder Unterstriche trennen Bezeichner aus mehreren Worten - Typen, Klassen, Module - Substantiv oder Nominalphrase - beginnend mit Grossbuchstaben - Schnittstellen und abstrakte Klassen - Substantiv, Nominalphrase oder Adjektivphrase - Beispiel: Cloneable, InputStream - Funktionen, Prozeduren und Methoden - mit Verb beginnend oder Verb enthaltend - Klassennamen in der Regel nicht wiederholen - Java: erster Buchstabe klein - C#: erster Buchstabe gross - spezielle Methoden: setze/set, hole/get, ist/is - Variablen, Attribute, Parameter - Ausdruecke mit Substantiv - erster Buchstabe klein - fuer Aufzaehlungen ist die Pluralform zu verwenden - Konstanten, Enumerationen - nie direkt verwenden, nur als symbolische Konstanten oder Enumerationen deklarieren - durchgehend gross geschrieben - durch Unterstrich getrennte Teilwoerter - Ausnahme: 0, 1, 2 - kurze Bezeichner fuer lokale Variablen: - b(yte), c(har), d(ouble), e(xception), f(loat), i, j, k, l, x, y, z, o(bject), s(tring) - jeder hat seine eigene implizite Bedeutung, z.B. o fuer Object oder s fuer String - Pakete - Substantiv, Nominalphrase, Abkuerzung - beginnend mit Grossbuchstaben * Implementierungsdokumentation + integraler Bestandteil jedes Programms (Kommentare) + Ziele - Angabe von Verwaltungsinformationen - Erleichterung der (Wieder-)Einarbeitung - Erleichterung der Wartung - Beschreibung der Entwicklungsentscheidungen - Festhalten der Verfeinerungsebenen + Vorspann - Name des Programms - Programmautor - Versionsnummer, Datum, Status - Freigabe-Nummer.Revisions-Nummer, z.B. V1.2 - Status kann sein: - geplant (V1.0) - in Bearbeitung (in Haenden des Implementierers) - vorgelegt (uebernommen in Konfigurationsverwaltung) - akzeptiert (von Qualitaetssicherung geprueft) - kurzgefasste Beschreibung der Aufgabe - Zeit- und Speicherkomplexitaet in O-Notation - eventuelle Aenderungshistorie + Kommentierung - in gleicher Sprache wie Code - nutze javadoc etc. - Beschreibung der Signatur jeder Methode, mindestens Beschreibung der Parameter, des Rueckgabewerts und der Ausnahmen - Beschreibung von Zusicherungen, Vorbedingungen, Nachbedingungen und Invarianten - Beschreibung von Fehlern und Maengeln - Beschreibung von Variablendeklarationen - Kommentar bei leerer Anweisung - Kommentar bei fehlender break-Anweisung + Dokumentation der Verfeinerungsebenen - Programm wird durch Abstraktionsebenen strukturiert - entweder wird jede Verfeinerungsebene kompakt beschrieben oder alle sind substituiert - Verfeinerung muss man sich nur ansehen, wenn man sich fuer die Details interessiert SELBSTKONTROLLIERTES PROGRAMMIEREN * der erfahrene Programmierer lernt aus seinen Fehlern -> Regelkreis des selbstkontrollierten Programmierens * typische Programmierfehler + Vorzugsweise werden nur Normalfaelle behandelt, dabei werden Sonderfaelle uebersehen - um-eins-daneben-Fehler, Indexzaehlfehler, Null-Zeiger-Zugriff + falsche Hypothesen - Multiplikationen dauern wesentlich laenger als Addition - Potenzieren ist aufwendiger als Multiplizieren - Cache-Effekte sind unwichtig + Tuecken der Maschinenarithmetik - Sonderfall der falschen Regeln - Computer haelt sich nicht an Regeln der Algebra - Reelle Zahlen werden nur mit begrenzter Genauigkeit dargestellt - immer abs(a-b) < epsilon und nicht a==b + irrefuehrende Namen + unvollstaendige Bedingungen + unverhoffte Variablenwerte + wichtige Nebensachen (die nicht als ganz so wichtig angesehen werden) + truegerische Redundanz - achtloses Kopieren - uebertriebene Kommentierung erhoeht Redundanz * Lernen aus Fehlern ist gut geeignet, um Denkfallen zu vermeiden + Anlegen eines eigenen Fehlerkatalogs - wenn Fehlersuche lange gedauert hat - wenn Kosten durch Fehler hoch waren - wenn Fehler lange unentdeckt geblieben ist +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ + Software-Qualitaetssicherung + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ EINFUEHRUNG UND UEBERBLICK * Definitionen + Qualitaet - Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer Taetigkeit, die sich auf deren Eignung zur Erfuellung gegebener Erfordernisse bezieht + Software-Qualitaet - Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfuellen + Qualitaetsmerkmale - der allgemeine Qualitaetsbegriff wird durch Ableiten von Unterbegriffen (Qualitaetsmerkmalen) operationalisiert + Qualitaetsmerkmale (factors) - Software-Qualitaet wird allgemein oder bezogen auf einzelne Entwicklungen durch Qualitaetsmerkmale beschrieben + Teilmerkmale (criteria) - Verfeinerung der Qualitaetsmerkmale + Qualitaetsindikatoren bzw. Metriken (metrices) - Mess- und bewertbar gemachte Teilmerkmale - Beispiele: Pfadlaenge, modularer Aufbau, Programmstruktur, Kommentierung, ... + Software-Qualitaetsmass - quantitative Skala oder Methode mit der ein Wert bestimmt werden kann, den ein Indikator fuer ein bestimmtes Software-Produkt aufweist - ein so aufgebautes Modell nennt man FCM-Modell (factor-criteria-metrics-model) - Teilmerkmale selbst koennen eine Hierarchie bilden - FCM-Modelle fuer Prozessqualitaet und Produktqualitaet * Software-Qualitaetsmerkmale + Funktionalitaet - Vorhandensein von Funktionen mit festgelegten Eigenschaften - erfuellen die Anforderungen - Richtigkeit - liefern die richtigen oder vereinbarten Ergebnisse - sind messbar ueber Fehlerdichte, mittlerer Ausfallabstand, ... - Angemessenheit - Eignung der Funktionen fuer spezifizierte Aufgaben - messbar ueber Umfragen, Anwendungsfalltests - Interoperabilitaet - Faehigkeit mit vorgegebenen Systemen zusammenzuwirken - messbar ueber eingehaltene Standards - Ordnungsmaessigkeit - Erfuellung von anwendungsspezifischen Normen, Vereinbarungen, gesetzlichen Bestimmungen etc. - messbar ueber eingehaltene Vorschriften - Sicherheit - Faehigkeit unberechtigten Zugriff, sowohl versehentlich als auch gewollt, auf Programme und Daten zu verhindern - messbar ueber Anzahl und Haeufigkeit von Zugriffsfehlern + Zuverlaessigkeit - Faehigkeit der Software, ihr Leistungsniveau unter festgelegten Bedingungen ueber einen festgelegten Zeitraum zu bewahren - Reife - geringe Versagenshaeufigkeit durch Fehlzustaende - messbar ueber Beobachtung der Nutzung und der Fehlerzustaende ueber die Zeit - Fehlertoleranz - Faehigkeit, ein spezifiziertes Leistungsniveau bei Software-Fehlern oder Nicht-Einhaltung ihrer Schnittstelle zu bewahren - messbar ueber Durchfuehrung von spezifikationsverletzenden Tests - Wiederherstellbarkeit - Faehigkeit, bei einem Versagen das Leistungsniveau wiederherzustellen und die direkt betroffenen Daten wiederzugewinnen - messbar ueber Beobachtung der Auswirkungen von Fehlern + Benutzbarkeit - Aufwand, der zur Benutzung erforderlich ist, und individuelle Beurteilung der Benutzung durch eine festgelegte oder vorausgesetzte Benutzergruppe - Verstaendlichkeit - Aufwand der Benutzer, das Konzept und die Anwendung zu verstehen - messbar ueber Benutzerbefragung - Erlernbarkeit - Aufwand die Anwendung zu erlernen - messbar ueber Zeit fuer das Erlernen einer Mindestfaehigkeit - Bedienbarkeit - Aufwand, die Anwendung zu bedienen - messbar ueber Zeit zur Erledigung von Anwendungsfaellen + Effizienz - Verhaeltnis zwischem dem Leistungsniveau der Software und dem Umfang der eingesetzten Betriebsmittel unter festgelegten Bedingungen - Zeitverhalten - Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausfuehrung - messbar ueber Aufgabe/Zeit oder Zeit/Aufgabe - Verbrauchsverhalten - Anzahl und Dauer der benoetigten Betriebsmittel fuer die Erfuellung der Funktion - messbar ueber Mindestspeicherbedarf, Prozessorenanzahl, ... + Aenderbarkeit - messbar ueber gewichtete Methode pro Klasse, Tiefe des Vererbungsbaumes, Anzahl der Kinder, Kopplung zwischen Objekten, etc. - Aufwand, der zur Durchfuehrung vorgegebener Aenderungen notwendig ist - Korrekturen, Verbesserungen oder Anpassungen - Analysierbarkeit - Aufwand, um Maengel oder Ursachen von Versagen zu diagnostizieren oder um aenderungsbeduerftige Teile zu bestimmen - Modifizierbarkeit - Aufwand zur Ausfuehrung von Verbesserungen, zur Fehlerbeseitigung oder Anpassung an Umgebungsaenderungen - Stabilitaet - Wahrscheinlichkeit des Auftretens unerwarteter Wirkungen von Aenderungen - messbar ueber Fehler, die durch Wartung hinzugefuegt wurden - Pruefbarkeit - Aufwand, der zur Pruefung der geaenderten Software notwendig ist + Uebertragbarkeit - Eignung der Software, von einer Umgebung in eine andere uebertragen zu werden - Anpassbarkeit - Software an verschiedene, festgelegte Umgebungen anpassen - messbar ueber erfuellte Standards - Installierbarkeit - Aufwand, der zum Installieren der Software in einer festgelegten Umgebung notwendig ist - messbar ueber Zeitdauer pro Installation - Konformitaet - Grad, in dem die Software Normen oder Vereinbarungen zur Uebertragbarkeit erfuellt - messbar ueber erfuellte Standards - Austauschbarkeit - Moeglichkeit, diese Software anstelle einer spezifizierten anderen in der Umgebung jener Software zu verwenden - messbar ueber erfuellte Standards TESTEN UND PRUEFEN * Ziele + je spaeter Fehler gefunden werden, umso teurer sind sie + so frueh wie moeglich Fehler finden + Testen aller Kombinationen ist nicht moeglich + formaler Beweis der Korrektheit meist nicht moeglich -> wann hoert man also auf zu testen ? * unterschiedliche Testverfahren + testende Verfahren + verifizierende Verfahren + analysierende Verfahren * Fehlerklassen + Anforderungsfehler (Fehler im Pflichtenheft) + Entwurfsfehler (Fehler in der Spezifikation) + Implementierungsfehler (Fehler im Programm) * Definitionen + Softwaretest - fuehrt eine einzelne Softwarekomponente oder eine Konfiguration von Softwarekomponenten unter bekannten Bedingungen aus und ueberprueft ihr Verhalten + Testling, Pruefling, Testobjekt - die zu ueberpruefende Komponente + Testfall - besteht aus einem Satz von Daten fuer die Ausfuehrung eines Teils oder des ganzen Testlings + Testtreiber oder Testrahmen - versorgen Testlinge mit Testfaellen und stossen Ausfuehrung der Testlinge an (interaktiv oder selbsttaetig) * V-Modell / Korrespondenz der Phasen + Anforderungsdefinition <-> Abnahmetest - Abnahmetest ist der abschliessende Test in realer Umgebung unter Beobachtung, Mitwirkung und/oder Federfuehrung des Kunden beim Kunden + Grobentwurf <-> Systemtest - Systemtest ist der abschliessende Test des Auftragnehmers in realer/realistischer Umgebung ohne Kunden + Feinentwurf <-> Integrationstest - Integrationstest ueberprueft schrittweise das fehlerfreie Zusammenwirken von bereits einzeln getesteten Systemkomponenten + Modulimplementierung <-> Komponententest - Komponententest ueberprueft die Funktion eines Moduls durch Beobachtung der Verarbeitung * Klassifikation testender Verfahren + dynamische Verfahren ("Testen") - Strukturtests (white/glass box testing) - kontrollflussorientiert - datenflussorientiert - funktionale Tests (black box testing) - Leistungstest (black box testing) + statische Verfahren ("Pruefen") - manuelle Pruefmethoden - Inspektionen - Reviews - Durchsichten / Walkthroughs - Pruefprogramme (statische Analyse) + dynamisch - das uebersetzte,ausfuehrbare Programm wird mit Testfaellen getestet - kein Korrektheitsbeweis, Stichprobenverfahren - blackbox: Bestimmung der Werte ohne Kenntnis von Kontroll- und/oder Datenfluss - whitebox: Bestimmung der Werte mit Kenntnis von Kontroll- und/oder Datenfluss + statisch - Programm wird nicht ausgefuehrt - Quellcode wird analysiert * Kontrollflussorientierte Testverfahren + Zwischensprache - besteht aus beliebigen Befehlen bis auf diejenigen, die die Ausfuehrungsreihenfolge beeinflussen - besteht aus bedingten Sprungbefehlen zu beliebigen aber festen Stellen - besteht aus unbedingten Sprungbefehlen zu beliebigen aber festen Stellen - besteht auf beliebig hoher Anzahl an Variablen + strukturerhaltende Transformation einer Quellsprache in Zwischensprache - nur Befehle, die die Ausfuehrungsreihenfolge beeinflussen, werden durch Befehlsfolgen der Zwischensprache ersetzt - alle anderen Befehle werden unveraendert uebernommen - keine Transformationen, bei denen Anweisungsfolgen oder bedingte Spruenge repliziert werden + Grundblock - bezeichnet maximal lange Folge fortlaufender Anweisungen der Zwischensprache, in die der Kontrollfluss nur am Anfang eintritt und die ausser am Ende keine Sprungbefehle enthaelt + Kontrollflussgraph G = (N, E, nstart, nstop) - N ist Menge der Grundbloecke - E Menge der Kanten, die die Ausfuehrungsreihenfolge von je zwei Grundbloecken angeben - Startblock und Stoppblock + Finden eines KFG - Transformation in Zwischensprache - zu Grundbloecken zusammenfassen - pruefen, ob Eintritt nur am Anfang, gegebenfalls neue Grundbloecke + Zweig - Kante e \in E - immer gerichtet + vollstaendiger Pfad - Pfade im KFG, die in nstart beginnen und in nstopp aufhoeren + Schleifenquerer - Teilpfad, der genau ein Mal einen Schleifenkoerper und die Bedingung einschliesst + BI-aequivalente Pfade - zwei Pfade, die sich ausschliesslich durch Anzahl oder Subpfade der Schleifenquerer unterscheiden + Grenztest - fuert zum Betreten aber nicht zum Wiederholen des Schleifenkoerpers + Interieurtest - fuehrt zum Betreten und mindestens einmaligen Wiederholen des Schleifenkoerpers + Anweisungsueberdeckung - verlangt Ausfuehrung aller Grundbloecke des Programms - C(anweisung) = Anzahl durchlaufener Anweisungen / Anzahl aller Anweisungen - nicht ausreichendes Testkriterium - nicht ausfuehrbare Programmteile koennen gefunden werden - Anwendbarkeit: nur, wenn keine Schleifen oder Bedingungen ausgefuehrt werden + Zweigueberdeckung - verlangt das Traversieren aller Zweige im KFG - C(zweig) = Anzahl traversierter Zweige / Anzahl aller Zweige - nicht ausgefuehrte Zweige koennen entdeckt werden - Schleifen nicht ausreichend getestet - fehlende Zweige nicht testbar - Anwendbarkeit: nur, wenn keine Schleifen und nur atomare Bedingungen vorhanden sind, sonst Boundary-Interior-Test und minimal-mehrfache-Bedingungsueberdeckung + Pfadueberdeckung - fordert die Ausfuehrung aller unterschiedlichen Pfade im Programm - Pfadanzahl bei Schleifen waechst dramatisch - manche Pfade nicht ausfuehrbar durch sich gegenseitig ausschliessende Bedingungen - Anwendbarkeit: ueberhaupt nicht praktikabel + Boundary-Interior-Pfadtest (immer fuer genau eine Schleife) - bilde Partitionen der Pfade und teste jeweils einen Repraesentanten jeder Partition - was muss getestet werden - unterschiedliche Pfade durch oberste Ebene des Programmes (ohne Betreten der Schleife) - unterschiedliche Pfade durch die Schleife (Interieurtest) - unterschiedliche Grenztests der Schleife (einmaliges Durchlaufen der Schleife) + Aequivalenzklassenbildung - aufteilen nach BI-aequivalenten Pfaden - dann diese Mengen nach unterschiedlichen Pfaden ausserhalb der Schleife aufteilen - dann diese Mengen nach Grenztestpfaden und Interieurtestpfaden aufteilen - dann die Grenztestpfadmengen nach verschiedenen Schleifenquerern aufteilen - und die Interieurtestpfadmengen nach Pfaden aufteilen, die im zweiten Durchlauf verschiedene Schleifenquerer verwenden - Teile alle Menge nach Pfaden auf, die die Schleife auf verschiedene Wege verlassen - waehle aus jeder Klasse einen Repraesentanten zum Test + Bedingungsueberdeckung + einfache BÜ - fordert, dass jede atomare Bedingung einmal mit W und einmal mit F belegt wird - Anwendbarkeit: enthaelt weder Zweig- noch Anweisungsueberdeckung, nicht ausreichend + mehrfache BÜ - fordert, dass die atomaren Bedingungen mit allen moeglichen Kombinationen belegt werden - exponentiell viele Kombinationen - Anwendbarkeit: meist zu komplex, enthaelt Zweigabdeckung + minimal-mehrfache BÜ - fordert, dass jede Bedingung, ob atomar oder zusammengesetzt, jeweils zu W und F evaluieren muss - invariante Bedingungen koennen entdeckt werden (unerfuellbare, tautologische Bedingungen) - Anwendbarkeit: enthaelt Zweigtest, gute Erweiterung dazu + Hierarchie - Pfadueberdeckung -> strukturierter Pfadtest -> BI-Test -> Zweigueberdeckung -> Anweisungsueberdeckung - mehrfache BÜ -> minimal-mehrfache BÜ -.....................-| -> einfache BÜ * Funktionale Tests - Testen der spezifizierten Funktionalitaet ist das Ziel - Testfaelle aus Spezifikation ableiten (Eingabedaten und erwartete Ausgabedaten/Sollwerte) - Interna unberuecksichtigt weil unbekannt + funktionale Aequivalenzklassenbildung - zerlege Wertebereich der Eingabeparameter und Definitionsbereich der Ausgabeparameter in Aequivalenzklassen + Grenzwertanalyse - verwende Elemente vom Rand + Zufallstest + Testen von Zustandsautomaten - wenn Komponente internen Zustand hat koennen Testfaelle aus den Zustandsuebergaengen abgeleitet werden - Ziel: mindestens einmaliges Durchlaufen aller Zustaende * Leistungstests + Lasttests - testet System / Komponenten auf Zuverlaessigkeit und Einhalten der Spezifikation im erlaubten Grenzbereich + Stresstests - Testen mit Ueberschreiten der definierten Grenzen * manuelle Ueberpruefung + nur so ist Semantik pruefbar - sehr aufwendig + Walkthrough / Durchsichten - Entwickler fuehrt Kollegen durch Code / Entwurf - diese stellen Fragen und machen Anmerkungen + Review / Ueberpruefung - mehr oder weniger formalisierter Prozess zur Ueberpruefung von schriftlichen Dokumenten durch externen Gutachter + Inspektion - Ueberpruefung anhand Prueflisten oder Lesetechniken - mehrere Inspektoren untersuchen das gleiche Software-Artefakt - gefundene Fehler werden aufgeschrieben und gemeinsam besprochen - Probleme werden zunaechst nur identifiziert, nicht geloest - Vorteile - immer anwendbar - auf alle Software-Dokumente anwendbar: Pflichtenheft, Code, Entwuerfe, Testfaelle, ... - effektiv in der Praxis - Nachteile - aufwendig - verbrauchen Zeit mehrerer Mitarbeiter - teuer - Phasen - Vorbereitung - Teilnehmer und Rollen festlegen - Dokumente vorbereiten - Lesetechniken festlegen - zeitlicher Ablauf planen - Individuelle Fehlersuche (IF) - jeder Inspektor prueft fuer sich - nutzt vereinbarte Lesetechnik - schreibt Problempunkte auf (Fragen, Fehler, Vorschlaege,...) - Gruppensitzung (GS) - sammeln der Problempunkte und jeden besprechen - Fragen klaeren - Vorschlaege sammeln - alternative Meinungen werden nicht diskutiert! - Nachbereitung - Liste mit Problempunkten an Editor - dieser aendert das Dokument - Prozessverbesserung - Prueflisten und Szenarien anpassen - Standards fuer Dokumente erarbeiten - Defekt-Klassifikationsschema anpassen - Formulare verbessern - Rollen - Inspektionsleiter - Moderator - Inspektoren - Schriftfuehrer - Editor - Autor - Lesetechniken - Ad-Hoc - Prueflisten - Szenarien - OO * Integrationstest + jede involvierte Komponente wurde bereits fuer sich getestet (Komponententest) + integriere eine weitere Komponente und teste und wiederhole + nutze Platzhalter (dummys) fuer nicht verwendbare Komponenten + nutze die gleiche Klassifikation wie bei Komponententests + Strategien - unmittelbar / inkrementell - vorgehensorientiert / testzielorientiert + unmittelbar - keine Testtreiber und Platzhalter notwendig - alle Systemkomponenten muessen fertig und ueberprueft sein - Fehler schwer zu lokalisieren - fuer grosse Systeme nicht geeignet + inkrementell - Testen fertiger Komponenten und Fertigstellung unfertiger Komponenten moeglich - Testfaelle sind einfacher - viele Testtreiber und/oder Platzhalter notwendig + vorgehensorientiert - Integrationsreihenfolge nach Systemarchitektur + testzielorientiert - ausgehend von Testzielen - die jeweils benoetigten kommen zusammen und werden getestet + Beispiele - big bang ("nichts geht bis alles geht") - geschaetsprozessorientiert (alle Komponenten integrieren, die vom Geschaeftsprozess betroffen sind) - funktionsorientiert (spezifiziert funktionale Testfaelle, schrittweise Integration und Test) - nach Verfuegbarkeit (Integration und Test sofort nach Abschluß ihrer Ueberpruefung, Reihenfolge vorgegeben durch Implementierungsreihenfolge der Module/Komponenten) - bottom-up (Integration niedrigster logischer Ebene, angefangen bei den Komponenten, die nicht selbst von anderen abhaengen) - top-down (Integration hoechster logischer Ebene) - hardest-first (zunaechst die kritischen Komponenten integrieren) - inside-out (Schrittweise Integration nach aussen in beide Richtungen) - outside-in (top-down und bottom-up, Integration in beide Richtungen) * Systemtest + System als Blackbox ansehen + Pruefung des Komplettsystems gegen Produktdefinition + reale Umgebung + funktionaler Systemtest - Ueberpruefung der funktionalen Qualitaetsmerkmale Korrektheit und Vollstaendigkeit + nichtfunktionaler Systemtest - Ueberpruefung nichtfunktionaler Qualitaetsmerkmale, Sicherheit, Benutzbarkeit, Interoperabilitaet, Dokumentation, etc. + Regressionstest - Wiederholung eines bereits vollstaendig durchgefuehrten Systemtests, aufgrund von Pflege, Aenderung und Korrektur etc. - Sicherstellung, dass sich System nicht in einen schlechteren Zustand als vorher befindet * Abnahmetest + spezieller Systemtest mit Kunden + Auftraggeber kann eigene Testfaelle durchfuehren etc. + formale Abnahme TESTWERKZEUGE * Amateure nutzen - Ausgabeanweisungen im Programm - interaktiver Debugger - Testskripte -> manuelle Ueberpruefung * Profis :D + nutze Zusicherungen - boolsche Funktionen (Vor und Nachbedingungen) - zur Laufzeit - koennen abgeschaltet werden - im Fehlerfall liefern sie Ausnahme oder Fehlermeldung - bei Ueberpruefung von Paramentern oeffentlicher Methoden keine Assertions sondern IllegalArgumentException + schreibe automatisch ablaufende Testfaelle, die sich selbst ueberpruefen - liefern boolschen Wert +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ + Abnahme-, Einfuehrungs-, Wartungs- und Pflegephase + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ * Abnahmephase + Uebergabe des Gesamtprodukts einschliesslich der gesamten Dokumentation an den Auftraggeber + meist folgt ein Abnahmetest mit der Uebergabe -> daraus resultiert ein Abnahmeprotokoll + formale Abnahme ist die schriftliche Erklaerung der Annahme im juristischen Sinne eines Produkts durch den Auftraggeber + Test haengt davon ab, ob Auftraggeber Produkt nur nutzt, ohne es zu warten und zu pflegen oder ob er es nutzt und selbst wartet und pflegt - Qualitaetsmerkmale wesentlich bei - Produktnutzung: Nutzbarkeit, Integritaet, Effizienz, Korrektheit und Zuverlaessigkeit - Wartung und Pflege: Wartbarkeit, Testbarkeit, Flexibilitaet + Test ueberprueft die Erfuellung der Qualitaetsmerkmale * Einfuehrungsphase + Installation des Produkts + Schulung der Benutzer + Inbetriebnahme -> Einfuehrungsprotokoll + bei Ersatz eines existierenden Systems Umstellung notwendig - Zeitplanung - was passiert mit den Datenbestaenden? - sind Konversionstools notwendig? - sind die entstandenen Daten auch korrekt? + direkte Umstellung - direkt vom alten zum neuen System - waehrend WE oder Feiertag - riskant (ohne Vorkehrungen) + Parallellauf - Bewegungsdaten werden sowohl im alten als auch im neuen System verarbeitet - hoehere Kosten - neue Probleme durch Parallellauf moeglich + Versuchslauf - entweder nimmt man Daten vom alten System, arbeitet mit diesen und ueberprueft Korrektheit - oder man fuehrt das neue System in einzelnen Stufen ein, indem Funktionsbereiche nach und nach aufgenommen werden + Pilotinstallation / Betatest - bei Produkten fuer den anonymen Markt wird eine Reihe von Pilotinstallationen vorgenommen * Abnahme- und Einfuehrungsphase + danach stoppt die Produktentwicklung + man erhaelt das Gesamtprodukt einschliesslich Gesamtdokumentation, Abnahmeprotokoll und Einfuehrungsprotokoll + Produkt unterliegt nun der Wartung und Pflege + im Wartungsarchiv werden von jedem Produkt verschiedene Versionen gespeichert * Wartungs- und Pflegephase + es treten Fehler nach Inbetriebnahme auf, Umweltbedingungen aendern sich, es existieren neue Wuensche oder Anforderungen + Klassifikation: es gibt korrektive und progressive Taetigkeiten + Stabilisierung / Korrektur - Fehler werden behoben + Optimierung / Leistungsverbesserung - alle Aktivitaeten um Leistung zu verbessern + Anpassung / Aenderung - aufgrund Wandlung der Umwelt + Erweiterungen - fuehren zu einer funktionalen Ergaenzung eines Produkts + andere Klassifikation: korrigierende, anpassende und perfektionierende Aktivitaeten + Wartung (Lokalisierung und Behebung von Fehlern) ist ereignisgesteuert, daher nicht planbar + Pflege (Lokalisierung und Durchfuehrung von Aenderungen) ist zeitlich festgelegt, also planbar + Verbesserung der Pflege - nur Produkt mit hoher Qualitaet freigeben - Trennung von Wartung und Pflege - alle Pflegeaktivitaeten (Weiterentwicklung) sollten den normalen Software-Entwicklungsprozess durchlaufen - immer hinterfragen: sollte Software saniert / durch ein neues ersetzt werden, wenn der Aufwand der Pflege / Wartung zu hoch wird - Sanieren ist das Verstehen alter Software und ihre Umwandlung in neue Software - Aenderungsmanagement (Erfassung und Verwaltung eingehender Fehlermeldungen, Problemmeldungen und Verbesserungsvorschlaegen) +~~~~~~~~~~~~~~~~~+ + SCHAETZMETHODEN + +~~~~~~~~~~~~~~~~~+ * Aufwandsabschaetzung + schwierig abzuschaetzen im voraus + sehr ungenau + aber entscheidend fuer Wirtschaftserfolg * Einflussfaktoren + Quantitaet - Groesse: LOC (lines of code) - Umfang: Problem, den Funktions- und Datenumfang exakt zu definieren - Komplexitaet: leicht, mittel, schwer + Qualitaet - proportional zum Aufwand, je qualitativer umso aufwendiger - nicht die Qualitaet, sondern die Qualitaetsmerkmale + Entwicklungsdauer - verkuerzte Zeite erfordert mehr Mitarbeiter - mehr Mitarbeiter erhoeht Kommunikationsaufwand - dieser reduziert die Produktivitaet - optimale Entwicklungsdauer = 2,5 * (Aufwand in MM)^s (s = 0,38 fuer Stapelverarbeitung, s = 0,35 fuer interaktive Systeme, s = 0,32 fuer Echtzeitsysteme) + Produktivitaet - Lernfaehigkeit und Motivation der Mitarbeiter - Programmiersprache - Ausbildung der Mitarbeiter, sind es KIT ? :D - Arbeitsklima + Kosten * Basismethoden + Analogiemethode - Vergleich der zu schaetzenden Entwicklung mit bereits abgeschlossenen Produktentwicklungen anhand von Aehnlichkeitskriterien - Anwendungsgebiet - Produktumfang - Komplexitaetsgrad - Programmiersprache - Programmierumgebung - intuitive Abschaetzung aufgrund von Erfahrungen - fehlende allgemeine Vorgehensweise + Relationsmethode - das zu schaetzende Produkt wird direkt mit aehnlichen Entwicklungen verglichen - Aufwandsanpassung erfolgt im Rahmen einer formalisierten Vorgehensweise - Faktorenliste und Richtlinien + Multiplikatormethode / "Aufwand-pro-Einheit"-Methode - das zu entwickelnde System wird soweit in Teilprodukte zerlegt, bis jedem Teilsystem ein bereits feststehender Aufwand zugeordnet werden kann - die Anzahl der Teilprodukte, die in einer Kategorie zugeordnet sind, wird mit dem Aufwand dieser Kategorie multipliziert + parametrische Schaetzgleichungen - durch Korrelationsanalysen wird ermittelt, welche Faktoren welchen wertmaessigen Einfluss auf den Gesamtaufwand haben - verlangt grosse Anzahl von abgeschlossen Entwicklungen, Vielzahl an Faktoren und viele Analysen - die Faktoren, die die hoechste Korrelation besitzen, werden zu einer Gleichung zusammengefasst - aehnlich Multiplikatormethode, Kategorien sind aber vorgegeben + Phasenaufteilung - aus abgeschlossenen Entwicklungen wird ermittelt, wie der Aufwand sich auf die einzelnen Entwicklungsphasen verteilt hat + Gewichtungsmethode - Faktoren werden festgelegt (subjektiv oder objektiv) - jeder Faktor hat einen Wert und diese werden dann mathematisch zu einer Formel verknuepft -> Funktionspunktmethode + Bewertung - fuer fruehzeitige, grobe Schaetzungen sollte man einsetzen - Analogieschaetzung - Relationsmethode - Phasenaufteilung - sind die Einflussfaktoren waehrend Entwicklung dann genauer bekannt, dann sollte eingesetzt werden - Gewichtungsmethode - Multiplikatormethode - Methode der parametrischen Schaetzgleichung FUNKTIONSPUNKTMETHODE * Allgemeines + Eingabe, Ausgabe, Anfragen und Datenbestaende werden in einer Anwendung bepunktet + Skalierung dieser Funktionspunkte durch Einflussfaktoren + abschliessende Umrechnung aufgrund historischer Daten in Mitarbeitermonate + kann erst eingesetzt werden, wenn Produktanforderungen bekannt sind (also ab Lastenheft) + Sicht des Auftraggebers * Schritte + jede Anforderung einer Kategorie zuordnen + Klassifizierung in einfach, mittel, komplex + Eintrag in Berechnungsformular + Bewertung der Einflussfaktoren + Berechnung der bewerteten Funktionspunkte + Ablesen des Monats in Mitarbeitermonate + Aktualisierung der empirischen Daten * Vorteile + Anforderungen sind Ausgangspunkt, nicht LOC + anpassbar durch Aenderung der Kategorie + anpassbar an neue Techniken durch Aenderung der Einflussfaktoren und Einflussbewertung + anpassbar an unternehmensspezifische Verhaeltnisse durch Aenderung der Einflussfaktoren, Einflussbewertung und Klassenfaktoren + Verfeinerung der Schaetzung entspricht Entwicklungsfortschritt + methodisch + leicht erlernbar + geringer Zeitaufwand noetig + Werkzeugunterstuetzung + gute Schaetzgenauigkeit * Nachteile + nur Gesamtaufwand + funktionsbezogen, Qualitaetsanforderungen nicht beruecksichtigt + subjektive Einflussfaktoren +~~~~~~~~~~~~~~~~+ + Prozessmodelle + +~~~~~~~~~~~~~~~~+ * Programmieren durch Probieren + code & fix oder trial & error + Vorgehen - Programm erstellen (vorlaeufig) - Anforderung, Entwurf, Testen, Wartung ueberlegen - Programm entsprechend verbessern + schnell (?), direkt Code ohne Zusatzaufwand + unsystematischer Code wegen fehlender Entwurfsphase + mangelhafte Aufgabenerfuellung wegen Fehlens der Anforderungsanalyse + Programme nicht auf Wartung / Pflege vorbereitet, kostspielig + keine Dokumentation + keine Aufgabenteilung, somit keine Teamarbeit moeglich * Wasserfallmodell / "Phasenmodell" + Planung --(Lastenheft, Glossar, Projektplan, Kalkulation)---> Definition + Definition --(Pflichtenheft, GUI-Beschreibung, eventuell Benutzerhandbuch)---> Entwurf + Entwurf --(Entwurfsdokumente, Modulfuehrer)---> Implementierung + Implementierung --(Komponenten und Dokumentation, Testeinrichtung)---> Testen + Testen --(fertiges System)---> Einsatz & Wartung + entgegengesetzte Richtung immer Validation + dokumentgetriebenes Modell, da am Ende jeder Aktivitaet ein Dokument steht + einfach und verstaendlich + Benutzerbeteiligung nur in der Definitionsphase + keine phasenuebergreifende Rueckkopplung, schwierig fuer Fehlersuche und Korrektur + keine Parallelitaet richtig moeglich * V-Modell (XT) + Aktivitaeten, Produkte und Verantwortlichkeiten werden festgelegt, ohne Reihenfolge + Projekt wird aus vielen moeglichen Rollen betrachtet + im alten V-Modell 4 Submodelle Projektmanagement, Qualitaetssicherung, Konfigurationsmanagement, Systemerstellung + V-Modell XT gliedert diese Submodelle in sogenannte Vorgehensbausteine + jedes Produkt durchlaeuft 4 Zustaende: geplant, in Bearbeitung, vorgelegt, akzeptiert + das uebliche V-Modell ist Spezialisierung auf das Wasserfallmodell * Prototypmodell + geeignet fuer Systeme, fuer die keine vollstaendige Spezifikation ohne explorative Entwicklung oder Experimentation erstellt werden kann + Prototyp entwerfen (eingeschraenkt funktionsfaehiges System) * Iteratives Modell / "succesive versions" + Erweiterung der Protoypidee, aber zumindest Teile lassen sich klar definieren + Funktionalitaet wird Schritt fuer Schritt erstellt und dem Produkt hinzugefuegt + es soll mehr weiterverwendet werden als beim Prototypmodell + evolutionaer: plane und analysiere nur den Teil, der als naechstes hinzugefuegt wird + inkrementell: plane und analysiere alles und iteriere dann n-mal ueber Entwurfs-, Implementierungs-, Testphase * Synchronisiere und Stabilisiere / "Microsoft-Modell" + organisiere x Programmierer zu Hackerteams, mit viel Freiheit + aber regelmaessige Synchronisation und Stabilisierung + Phasen: Planungsphase, Entwicklungsphase, Stabilisierungsphase + Vorteile - effektiv durch kurze Produktzyklen - Priorisierung nach Funktion - natuerliche Modularisierung nach Funktionen - Fortschritt auch ohne vollstaendige Spezifikation - Teamarbeit + Nachteile - ungeeignet fuer manche Art von Software, mangelhafte Fehlertoleranz, etc. - muendliche Arbeitsweise, kein Lernen ueber Teamgrenzen - Code wird zu oft ueberarbeitet * Agile Prozesse / Extreme Programming + Grundgedanke: - Individuen und Interaktion wichtiger als Prozesse - laufende Software wichtiger als Dokumentation - Kundenmitarbeit wichtiger als Vertragsverhandlungen - sich auf Aenderungen einstellen wichtiger als Verfolgen eines Plans + Agile Prozesse - Eigenschaften - Minimum an Vorausplanung - Planung inkrementell - Vermeidung unterstuetzender Dokumente - schnellste Reaktion auf Aenderungen - Einbeziehung der Kunden in die Entwicklung + XP-Praktiken - Paarprogrammierung - testgetriebene Entwicklung - inkrementelles Design durch Umstrukturieren - iterative Planung in kurzen Zyklen - Beteiligung eines echten Kunden - textuelle Beschreibung der Anwendungsfaelle auf Karteikarten - fortlaufende Integration - gemeinsamer Codebeisitz - Programmierrichtlinien + Paarprogrammierung - an einem Rechner - einer denkt an Implementierung - der andere denkt strategisch, fuehrt staendige Durchsicht durch - effizient und qualitativ besser? Ressourcenverschwendung Mensch? - Testen moeglichst zeitnah, automatisiert und wiederholbar - Testen soll einfach und so oft wie Kompilieren passieren - Fehler finden, nicht Fehlerfreiheit beweisen - Testcode vor Anwendungscode - fehlschlagender Test gibt an, welcher Code als naechstes geschrieben wird + Umstrukturierung / Refactoring - moeglich nur, wenn automatische Tests vorhanden sind, da sie ein lauffaehiges Produkt nach der Umstrukturierung sicherstellen - Ziel: moeglichst einfache Form - alle Tests erfuellt - vom Zielpublikum wird Code verstanden - Intention der Programm wird ausgedrueckt - keine duplizierte Logik vorhanden - moeglichst wenig Klassen und Methoden - Reihenfolge entscheidend - Aenderung bei faulen Geruechen (bad smells) im Code - duplizierter Programmtext - parallele Vererbungsbaeume - Schrotflintenchirurgie - Kommentare zu umfangreich, Code zu komplex + inkrementelles Design - implement for today, design for tomorrow - kleine inkrementelle Designschritte statt grosser Entwurfsphase + Planungsspiel - Ziel: Planung von Umfang, Zeit und Kosten der naechsten Iteration / der naechsten Auslieferung - Plan aendert sich staendig + Kritik - asymptotische Kostenkurve auf Erfahrung einzelner Personen - fehlende Produktdokumentation - nicht reproduzierbarer Prozess - Paarprogrammierung kostenintensiv, wirklich effizienter? - Kunde muss mitarbeiten - testgetriebene Entwicklung fordert Umdenken - gleiche "Wellenlaenge" bei Paarprogrammierung + Lob - Planungsschritte vorhanden - Tests immer vorhanden - Programmierer werden diszipliniert - leichte Planung nach Wasserfallmodell - geeignet fuer vage und sich aendernde Anforderungen - fuer kleine Entwicklerteams +~~~~~~~~~~~~~~~~~~~~~~~~~~+ + Konfigurationsverwaltung + +~~~~~~~~~~~~~~~~~~~~~~~~~~+ * Konfigurationsverwaltung + Arguemente fuer Konfigurationsverwaltung - verschiedene Dateisysteme - unterschiedliche Rechner - diverse Plattformen unterstuetzt - mehrere Teams / Firmen - geographisch verteilte Entwicklerteams moeglich + stellt einen Mechanismus zur Identifizierung, Lenkung und Rueckverfolgung der Versionen jedes Software-Elementes dar + Softwarekonfiguration - benannte und formale freigegebene Menge von Softwareelementen, mit den jeweils gueltigen Versionsangaben, die zu einem bestimmten Zeitpunkt im Produktlebenszyklus in ihrer Wirkungsweise und ihren Schnittstellen aufeinander abgestimmt sind und gemeinsam eine vorhergesehene Aufgabe erfuellen sollen + Softwareelement - jeder identifizierbare Bestandteil des entstehenden Produkts oder der entstehenden Produktlinie - besitzt systemweit eindeutigen Bezeichner - Aenderung fuehrt zu neuem Bezeichner - Quellelement: manuell erzeugt - abgeleitetes Element: automatisch generiert + Version - Auspraegung eines Softwareelements zu einem bestimmten Zeitpunkt + Revisionen - zeitliche nacheinander liegende Versionen (Entwicklungsstaende) + Varianten - alternative Versionen (Anpassungen) + Versionsnummern - bestehen aus Freigabenummer (release) und laufender Nummer (level) - Release.level - neues Softwareelement erhaelt Versionsnummer 1.0 - bei jeder Aenderung wird laufende Nummer um 1 erhoeht: 1.1, 1.2, ... + Softwareelemente werden in Archiven gesammelt - Ausbuchen / Check-Out - holt Kopie aus Archiv - reserviert Kopie fuer Ausbucher, was heisst, dass nur dieser die naechste Revision ablegen darf (striktes Ausbuchen) - Einbuchen / Check-In - schreibt Kopie in Archiv zurueck - loescht Reservierung - Historie (wer, wann, welche Aenderungen, ...) + Problematik: Dateien koennen mehrfach ausgebucht sein - striktes Ein-/Ausbuchen - nur eine Ausbuchung gleichzeitig ist erlaubt - keine Kollision - dafuer darf nur einer aendern - optimistisches oder mehrfaches Ein-/Ausbuchen - mehrere Ausbuchungen erlaubt - mehrere Entwickler koenen dran arbeiten - Aufwand beim Zusammenfuehren der Versionen (der Schnellere gewinnt) + sequentielle Versionsstaemme reichen oft nicht aus, deswegen Varianten - Bearbeiten aehnlicher Versionen - parallele Entwicklungslinie - Anpassungen an unterschiedliche Bibliotheken, GUIs, Nutzer, Hardware, Betriebssystem, etc - Release.Level.Variante.Level - erste Variante von Version 2.3 ist 2.3.1.0 - dritte Level der 4. Variante von Version 1.7 ist 1.7.4.3 + Konfiguration umfasst bestimmte Versionen von Softwarelementen - Konfigurations-Identifikationsdokument bestimmt Zuordnung von Konfiguration zu Versionen der Softwareelemente - KID nutzt selbst Versionsnummern - Beispiel: SE1 V1.2 / SE2 V1.5 / SE3 V2.2 / SE4 V1.3 bilden Konfiguration V1.0 - Konfigurationen sollten angelegt werden, wenn Ergebnis einer Entwicklungsphase vorliegt, z.B. Anforderungsanalyse, Entwurf, etc. + Interne Verwaltung von Versionen - vollstaendiges Abspeichern waere zu speicherintensiv - nutze Vorwaertsdeltas: speichere Grundversion und die daran durchgefuehrten Aenderungen - schneller Zugriff auf fruehere Versionen - langsamerer Zugriff auf aktuellere Versionen - nutze Rueckwaertsdeltas: speichere aktuelle Version und die Aenderungen fuer fruehere Versionen - da aktuelle Version wichtiger ist, nutze Rueckwaertsdeltas - dabei ist Delta der Unterschied zwischen zwei Versionen - bei Varianten wiederum Vorwaertsdeltas nutzen * Revision Control System + verwaltet mehrere Versionen einer Datei - automatisiert - Aufbewahrung - Wiederherstellung - Logging - Identifikation - Verschmelzen von Versionen + Benutzerschnittstelle - ci, co, rcs, rlog - RCS-Dateien sind alle Dateien im Archiv - Arbeitsdateien sind alle anderen + rcs i DATEINAME - Anlegen eines neuen Archivs fuer Datei DATEINAME - leeres Archiv - Beschreibung wird verlangt, nicht Logbucheintrag + ci DATEINAME - legt Datei im Archiv ab - loescht Datei im Arbeitsverzeichnis + co DATEINAME - bucht neueste Version der Datei aus Archiv heraus - nun im Arbeitsverzeichnis - nicht zum Aendern geeignet, da keine Reservierung + co -l DATEINAME - zusaetzlicher lock fuer die Datei - striktes check-out - erst nach ci DATEINAME lock aufgehoben + rlog DATEINAME - zeigt an: Pfad zu RCS-Datei, Pfad zu Arbeitsdatei, Kopfversion, Zweige, Zugriffsliste, symbolische Namen + keine Sicht auf mehrere Dateien gegeben -> CVS * Concurrent Version System + erweitert Versionierung auf ganze Verzeichnisse und deren Inhalt + nutzt optimistisches Aus-/Einbuchen + cvs -d /usr/share/projects checkout oder + set CVSROOT="/usr/share/projects" cvs checkout + entfernte Archive: [:method][[:user][:password]@]hostname[:[port]]/Server/Pfad - z.B. :pserver:ranjid:foobar@hostname.de/usr/share/repository + cvs init legt neues Archiv an + cvs login/logout + cvs import -m "Beschreibungstext" - vendor tag: von wem kam die Quelle - release tag: Markierung fuer spaetere Zugriffe + cvs checkout - legt lokal Verzeichnis an und kopiert Hauptzweig dahin + cvs update - aktualisiert lokale Dateien mit neuen Versionen aus dem Archiv, die seit dem Ausbuchen neu abgelegt wurden - moegliche Konflikte in separater Datei + cvs commit - schreibt Verzeichnis/Dateien ins Archiv zurueck - erhoeht Revisionsnummer der veraenderten Dateien + cvs tag - markiert letzte Version im Hauptzweig in mit - eindeutige Identifizierung von Konfiguration + diff - findet Differenzen zwischen lokaler Kopie und Archiv +~~~~~~~~~+ + XML 1.0 + +~~~~~~~~~+ * was ist XML ? + eXtensible Markup Language + Standard um strukturierte Dokumente im Internet von Anwendung zu Anwendung auszutauschen - strukturiert: Attribut-Werte-Paare, baumartig gegliedert - einfach anwendbar von Anwendungen - Unicode Klartext - unabhaengig von Plattform, Programmiersprache, Anwendung + Markup / Auszeichnung - alle zusaetzlichen Zeichen und Zeichenfolgen, die in einem Dokuemnt enthalten sind, aber nicht zu den eigentlichen Daten gehoeren + XML Dokument - besteht aus Prolog gefolgt von Wurzelelement - - Elemente bestehen aus Start- und Endmarke, Beispiel foobar - Elemente koennen mit Attributen annotiert werden (innerhalt Startmarke) - alle Elemente muessen Startmarke und Endmarke, bis auf leere Elemente, dann - besitzen eine zugehoerige DTD (document type definition), die vorgibt, welche Elemente und Attribute an welchen Stellen vorkommen duerfen * Document Type Definition + Beispiel ]> + Wurzelelement steht nach Kapitel 1 * XML Schema + DTD ist unbefriedigend, da keine Hierarchie moeglich ist und nur primitive Typen moeglich sind wie CDATA, ID, etc. + ein XML Schema ist selbst ein XML Dokument + definitions + XSD Typen - atomare Typen und aggregierte Typen - primitive und abgeleitete Typen - vorgegebene und anwenderdefinierte Typen - string, normalizedString, token, decimal, integer, long, int, short + Element - - - + weitere Eigenschaften von Elementen - abstract: Element kann nicht in einem Instanzdokument verwendet werden, sondern es muesen noch Ersatztypen deklariert werden - block: verbietet Ersetzung dieses Typs in Instanzdokumenten mit Instanzen von abgeleiteten Typen - default: definiert Standardwert - final: verbietet Typableitungen von diesem Typ - fixed: legt bestimmten Wert fest - minOccurs: legt fest, wie oft Element vorkommen muss - maxOccurs: legt fest, wie oft Element vorkommen darf