zusammenfassung swk

ZUSAMMENFASSUNG SWK 01 – Komponenten: Definition des Komponentenbegriffs ‐ Aus dem lateinischen compnere (zusammensetzen) ‐ „Eine Software‐Komponente ist ein Software‐Element, das zu einem bestimmten Komponentenmodell passt und entsprechend einem Composition Standard ohne Änderungen mit anderen Komponenten verknüpft und ausgeführt werden kann.“ Komponentenmodelle ‐ Komponentenmodelle sind konkrete Ausprägungen des Paradigmas der Komponentenbasierten Entwicklung. Neben der genauen Form und den Eigenschaften einer Komponente muss es einem Interaction‐Standard und einen Compostition‐Standard festlegen. Ein Komponentenmodell kann ausserdem Implementierungen verschiedener Hersteller besitzen. ‐ Folgende Komponentenmodelle sind weit verbreitet: ‐ MS .NET ‐ Enterprise Java Beans ‐ DCOM (Distributed Component Object Model) ‐ CORBA Component Model Subsysteme Der Komponentenbegriff ist hierarchisch Wichtige Eigenschaften von Komponenten ‐ eigenständige, ausführbare Software‐Einheiten (Laufzeit‐Sicht), d.h. Subsysteme, Prozesse, Objekte ‐ über ihre Schnittstellen austauschbar definiert ‐ lassen sich unabhängig voneinander entwickeln ‐ kunden‐/ anwendungsspezifische, bzw. wiederverwendbare Software sowie COTS ‐ können installiert / deployed werden Komponentenbasierte Entwicklung ‐ Die Konstruktion von Software aus vorgegebenen Komponenten und Bibliotheken spielt eine immer grössere Rolle, da die Komplexität von Systemen, Protokollen und 1 | Chrösch Anwendungsszenarien anwächst und damit eine Eigenentwicklung aus Gründen der Wirtschaftlichkeit und Sicherheit nicht ratsam erscheint. ‐ Die Schwierigkeit der Softwareentwicklung liegt heute nicht in der Beherrschung der gewählten Programmiersprache, sondern vielmehr in der der zugehörigen Bibliothek (vgl. die Komplexität der Sprache Java und die des JDK) ‐ Komponenten zu entwickeln, stellt hierbei noch höhere Anforderungen an unsere softwaretechnischen Fertigkeiten als reguläre Software, da eine ganze Reihe neuer Einflüsse beachtet werden müssen, die bei einmaliger Anwendung nicht auftreten. Nutzen von Komponenten ‐ Packaging: Reuse Benefits Contatin Vomplexity – divide and conquer Reduced delivery time reuse is quicker than build less testing needed Greater Consistency “standard” components Ability to leverage “Best in Class” competition and market forces ‐ Service: Interface Benefits Increased Productivity assemblies of existing components Higher Quality precise specifications pre‐tested ‐ Integrity: Replacement Benefits Incremental Development and Test extendible specifications Parallel and Distributed Development precise specifications managed dependencies Improved Maintenance encapsulation limits impact of change Praktische Eigenschaften von Komponenten ‐ Wer eine Komponente einsetzen will, brauch nur deren Schnittstelle zu kennen. ‐ Komponenten, die dieselbe Schnittstelle haben, sind gegenseitig austauschbar. ‐ Komponententest ist blackbox Test. ‐ Komponenten lassen sich unabhängig voneinander entwickeln. ‐ Komponenten unterstützen die Wiederverwendbarkeit. Verhaltenssicht ‐ Componentes & Connector: ausfürhbare Einheiten und gemeinsame Daten ‐ Datenfluss: Data flow between components. ‐ Control flow: wird angestossen von… ‐ Prozess: welche Komponenten laufen parallel? ‐ Verteilung: Zuordnung der Komponenten zur Hardware 2 | Chrösch Komponenten‐Spezifikation Export: unterstütze Interfaces, die andere Komponenten nutzen können. Import: benötigte / benutzte Interfaces von anderen Komponenten. Verhalten: Verhalten der Komponenten. Kontext: Rahmenbedingungen im Betrieb der Komponente. Architektur‐Muster Pipe‐and‐Filter ‐ Component: Filter ‐ Connector: Pipe ‐ Data Transformation Shared Data ‐ Component: Repositories ‐ Connector: Data Reader/Writer ‐ Multipe Accessors & Persistence Publish‐Subscribe ‐ Component: any ‐ Connector: publish‐subscribe ‐ Send events & msgs. to unknown set of recipients Client‐Server ‐ Component: Client und Server ‐ Connector: request/reply ‐ Decoupling Apps. from Services Peer‐to‐Peer ‐ Component: Peer ‐ Connector: bidirectional RPC ‐ Collaboration Communicating Processes ‐ Component: any concurrent unit ‐ Connector: data exchg., msg. passing, sync., ctrl. ‐ Concurrent Systems 3 | Chrösch 02 – Konfigurationsmanagement: Konfigurations‐Management ‐ In einem System sind Software (möglicherweise mehrere Komponenten, dazu gehörige Einstellungen, Hardware, Firmware und Dokumentation laufend Änderungen unterworfen. ‐ Weil nicht alle Versionen aller Teile korrekt miteinander funktionieren, ist ein Konfigurations‐Management nötig, sobald ein System aus mehreren Teilen besteht. Begriffe ‐ Die Konfiguration bezeichnet eine bestimmte Kombination von Versionen der Systemteile (Hardware, Firmware, Software, Dokumentation). ‐ Eine Version ist ein spezifisches, identifizierbares Artefakt auf einem bestimmten Entwicklungsstand. ‐ Ein Release ist eine getestete und freigegebene Konfiguration. Versionskontrolle ‐ Dokumente entstehen und verändern sich im Laufe jedes Entwicklungsprozesses, nicht nur bei iterativ‐inkrementellem Vorgehen. ‐ Es ist daher wichtig, den Stand eines Dokumentes zu kennen. ‐ Vielfach ist es eine Prozessvorgabe, dass die Produktentstehung aus den Dokumenten nachvollziehbar sein muss. Dokumente müssen einer Versionsverwaltung unterworfen werden. Umgang mit Änderungen Beim iterativ‐inkrementellen Vorgehen haben verschiedene Releases unterschiedliche Spezifikationen und Architekturen, die möglicherweise untereinander nicht konsistent sind. ‐ Konsistente Versionen in entsprechenden Unterkapiteln oder konsistente Versionen der Systemspezifikation pro Release ablegen 4 | Chrösch Software Configuration ‐ The configuration of a system is the function and/or physical characteristics of hardware, firmware, software or a combination thereof as set forth in technical documentation and achieved in a product. ‐ It can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to accomplish a particular purpose. Software Configuration Management (SCM) Software Configuration Management heisst die Disziplin, die Konfiguration eines Systems zu bestimmten Zeitpunkten zu erfassen, um Änderungen daran systematisch und kontrolliert durchzuführen und die Integrität und die Nachvollziehbarkeit von Konfigurationen während der gesamten Lebensdauer sicherzustellen. ‐ restriktives Modell: SCC, RCS, … Entwickler holen sich bestimmte Versionen von Dateien (check out) zum Lesen / Benutzen (beliebig viele Entwickler gleichzeitig) zum Schreiben (Verbessern, Ändern, Weiterentwickeln etc.) maximal ein Entwickler zu einem Zeitpunkt Nur Daten die aus dem Repository geholt wurden können geändert werden (check in) 5 | Chrösch ‐ optimistisches Modell: CVS, Subversion (SVN), … Entwickler holen sich bestimmte Versionen von Daten (check out / update) Geändert werden können alle Daten (commit); Annahme: Es werden selten Konflikte zwischen Änderungen auftreten Software Configuration Item (SCI) ‐ A software configuration item is an aggregation of software that is designated for configuration management and is treated as a single entity in the SCM process. ‐ Items that are controlled by SCM in addition to the code itself include plans, specifications, code libraries, data and data dictionaries, and documentation for installation, maintenance, operations etc. SCM Begriffe ‐ Eine Version ist ein spezifisches, identifizierbares Artefakt auf einem bestimmten Entwicklungsstand. ‐ Eine Revision ist eine neue Version eines Artefaktes mit dem Zweck eine ältere abzulösen. ‐ Eine Baseline ist ein Satz von Revisionen, d.h. ein Snapshot der Konfiguration. ‐ Ein Release ist eine getestete und freigegebene Baseline. 6 | Chrösch Hauptsächliche SCM Aktivitäten ‐ Software Configuration Identification ‐ Software Configuration Control ‐ Software Configuration Status Accounting ‐ Software Configuration Auditing ‐ Software Release Management and Delivery Nutzen des SW‐Konfigurationsmanagement ‐ Aus Managersicht verwaltet das Software‐Konfigurationsmanagement die Evolution eines Produktes in dem dessen Komponenten identifiziert, Änderungen verwatlet und geregelt, Konfigurationsdaten überprüft, abgelegt und weiter gegeben werden und so die Integrität des Produktes sicher gestellt wird. ‐ Aus Entwicklersicht unterstützt das Sowftware‐Konfigurationsmanagement die Entwicklungs‐ und Änderungsprozesse. ‐ Software wird oft als Teil eines grösseren Systems, das auch Hard‐ und Firmware enthält entwickelt. Daher muss das Software Konfigurationsmanagement mit dem Hard‐ und Firmware‐Konfigurationsmanagement abgestimmt werden. 7 | Chrösch 03 – Schnittstellen: Kriterien für Schnittstellen ‐ Schnittstellen sollen minimal sein wenig Methoden Methoden sollen verschiedene Aufgaben wahrnehmen wenig Überschneidungen geringe Anzahl von Parametern möglichst wenige (gar keine) globale Daten ‐ Schnittstellen sollen einfach zu verstehen sein ‐ Schnittstellen sollen gut dokumentiert sein Minimalität der Schnittstelle ‐ möglichst wenige (gar keine) globale Daten Verlust der Kontrolle ‐ wenige exportierte Methoden Methoden des Moduls stark verbunden je mehr exportiert, desto eher falsche Verwendung ‐ geringe Anzahl von Parametern viele oder komplexe (Klassen / struct) Parameter viele Variationen komplizierte Verwendung Perspektiven Dienstleistungsperspektive Service Perspektive Interface Typen Operational Interface: A component offers a range of services, which are accessed by calling interface operations. Signal Interface: A set of signals that can be sent or received by a component. Stream Interface: Collections of data‐streams, that can be consumed or produced by a component. 8 | Chrösch Operational Interfaces Control‐ and Data‐flow ‐ Operational Interfaces group operations belonging together. ‐ If a client uses one operation, it is quite likely that it will use some of the other operations too. ‐ Sets of such operations belong together and have related effects on the state of the component object. Specification (from the interface provider’s pint of view) ‐ The name of the interface ‐ The input parameters (specifying the information passed to the component) ‐ The output parameters (specifying the information provided or returned by the component) ‐ Any resulting change of state of the component ‐ Specification how the inputs, outputs and component states are related Stream‐ and Signal‐Interface Specification (from the interface provider’s point of view) ‐ Stream Interface: the name of the interface produced streams (outgoing) consumed streams (ingoing) quality of services (e.g. max. dataflow) ‐ Signal Interface: the name of the interface outgoing signals ingoing signals Schnittstellen‐Entwurf / Coupling and Collaboration ‐ Using data of another subsystem needs knowledge about its interior design. ‐ If you change the subsystem that provides the data, you also have to take care of the other subsystem. ‐ Since you can also use memory pointers to access data, a later dependency analysis may easily become impossible On the other hand, there is nothing you can do with shared data you cannot do with message passing, so avoid shared data. 9 | Chrösch Einige Definitionen ‐ statically coupled (statische Kopplung) one class needs the definition of another class to compile ‐ dynamically coupled (dynamische Kopplung) instances send messages to each other at run time ‐ transitivity (Transitivität) The interface of a method also contains parameters, which in most cases not atomic data types but complex classes, which you also have to know. You often find circles in the transitive closure of a class which means, that every class participating in the circle needs every other class to compile. Interface Without Decoupling Instrument Interface of a Medical Laboratory Manager. Client classes, addressing a certain instrument, have to cope with the complete web of objects. Î Strictly layered structure ‐ much effort Decoupling with a Subsystem Facade The Instrument Façade reduces external coupling. The coupling between subsystem classes is still tight. … it may as well hide legacy code. 10 | Chrösch Facade Design Pattern Structure Facade Implementation ‐ You may model the Facade as a class. ‐ Depending on the domain aspects you have two alternatives to choose from ‐ The Facade may either be a Singleton If the subsystem I a book‐keeping system and the Facade only offers use‐cases, it may as well be a Singleton ‐ or you may decide to allow multiple instances of it If the subsystem implements communication issues, for example, every instance of the Facade may represent a separate connection. How to Instantiate Objects Inside? ‐ Clients are responsible: To preserve encapsulation, the Facade needs special methods to create the corresponding objects. ‐ Facade is responsible: The clients are unaware about creation and deletion of subsystem objects. This solution works best, when multiple clients address a single server with a stateless protocol. Be sure that the Facade is the only way to access the subsystem. ‐ Subsystem objects are responsible: There are factories inside the subsystem that know, when to instantiate certain objects and when to destroy them. This is the most radical approach where even the Facade is not aware of object instantiation. 11 | Chrösch 04 – Projektplanung: Regelkreis/Kernelemente der Projektabwicklung ‐ Projektplanung (Prozess) Projektplanung Steuerung Kontrolle ‐ Projektdurchführung (Produkt) Phasenmodell Vorgehensmodelle Phasenmodell (Generisch – nach Jenny) ‐ Phasenweises Vorgehen hilft den Überblick zu behalten ‐ Risiko einer Fehlentwicklung wird verringert ‐ Periodische Stellungnahmen und Entscheide an den Meilensteinen M1 … M4 ‐ Lieferobjekte am Ende jeder Phase sind klar Initialisierungs‐Phase Was wollen wir tun? Konzeptions‐Phase Wie wollen wir es tun? Realisierungs‐Phase Wir realisieren unsere Lösungen. Einführungs‐Phase Sind die Projektziele erfüllt? Projektauftrag / Projektdefinition / Problemanalyse / Ziel und Anforderungsdefinition / Definition der Arbeitspakete Konzept‐ und Lösungssuche Fertigung, Programmierung etc. Das neue Produkt wird für den Gebrauch, Verkauf freigegeben. Gestaltungsprinzipien Top‐Down‐Prinzip ‐ Vom Groben zum Detail ‐ Konzept auf oberer Ebene gilt als Orientierungshilfe ‐ Es liegen nicht sofort konkrete Lösungen vor Bottom‐Up‐Prinzip ‐ Verbesserung vorhandener Lösungen ‐ Es liegen schnell Lösungen vor 80/20‐Prinzip (Pareto‐Prinzip nach ital. Ökonom Vilfredo Pareto 1897) ‐ Eine Minderheit von Ursachen führen zu einer Merheit von Ergebnissen 12 | Chrösch Software Entwicklungsprozess Aufwandverteilung Ziel der methodischen Entwicklung ist Verlängerung der Lebensdauer Reduktion der Kosten der Wartungsphase ‐> evt. grössere Anfangskosten! Frühere Phasenmodelle Wasserfallmodelle ‐ Sequentielles Vorgehen ‐ Phasen = Aktivitäten ‐ Kontrolle der Aktivitätenergebnisse und Tests V‐Modelle ‐ Sequentielles Vorgehen ‐ Phasen haben Bezug zum „aufsteigenden Ast“ ‐ Unterscheidung von Review, Verifikation und Validierung Probleme des sequentiellen Vorgehens Fehler werden spät erkannt: Folgen bei vermeintlich „seriösem Vorgehen“ (jede Phase muss abgeschlossen sein, bevor mit der nächsten angefangen wird): ‐ späte Entdeckung von Anforderungs‐ Analyse‐ und Designfehlern erst im Integrations‐ bzw. Abnahmetest ‐ Risiken werden zu lange mitgeschleppt, weil „jetzt noch nicht codiert werden darf“ Neuere Phasenmodelle Iterativ ‐ Die Aktivitäten des Entwicklungszyklus werden mehrmals durchlaufen. ‐ Bereits in frühen Iterationen werden lauffähige Programmteile geschaffen (Prototypen). Inkrementell ‐ Die Releases erhalten mit jeder Iteration einen grösseren Funktionsumfang 13 | Chrösch Projektplanung im HTAgil (Plans are nothing – Planning is everything) Grobterminplanung 1. Die wichtigsten Meilensteine des Projektes benennen 2. Meilensteine vom Ausliefertermin her rückwärts verteilen 3. Deliverables der ersten Iteration benennen (besser wenige, dafür möglichst früh) 4. Punkte im Projektverlauf aufzeigen, wo Risiken beurteilt werden 5. Reserve für Unvorhergesehenes einplanen Rahmenplan: „big‐picture“ ‐ Die groben Iterationsschritte und die dazugehörigen Meilensteine können in einem ersten Schritt aus dem HTAGil Phasen abgeleitet werden. ‐ Insbesondere die Konstruktionsphase wird oft durch weitere Meilensteine (Auslieferung unterschiedlicher Software Releases) weiter strukturiert. ‐ Der Rahmenplan sollte möglichst stabil sein. The Cone of Uncertainty (http://www.codinghorror.com/blog/archives/000623.html) The cone defines statistically predictable levels of project estimate uncertainty at each stage of the project. Estimates created at initial concept time can be inaccurate by a factor of 4x on the high side or /4 on the low side. ‐ The Cone of Uncertainty represents the best‐case accuracy. It isn’t possible to be more accurate; it’s only possible to be luckier. ‐ Furthermore, the cone doesn’t narrow itself. If you don’t actively work to reduce the variability of your project, the cone of uncertainty quickly becomes a cloud of uncertainty. 14 | Chrösch Arbeitsplanung und Schätzgenauigkeit Die Arbeitsplanung erfolgt rollend, d.h. innerhalb des Rahmenplanes werden die nächstfolgenden Iteration geplant. Mögliche Ansätze: ‐ Zeitorientiert (Timeboxing): Fixe Zeitabschnitte, in der rollenden Planung werden die Ziele für eine Iteration entsprechend festgelegt. ‐ Artefaktorientiert: Für jede Iteration werden Deliverables definiert. Die Iterationsdauer wird entsprechend geplant. Bottom‐Up Terminplanung 1. Aufteilung des zu entwickelnden (Software‐)Systems in eine überschaubare Anzahl (<50) von intuitiv abgrenzbaren Einheiten (Subsysteme, Komponenten, …). Hardware Strukturierung: Technische Systeme lassen sich meist entlang von Hardware‐Grenzen in Subsysteme und Komponenten gliedern. Fachliche Strukturierung: Business‐Anwendungen lassen sich typisch funktional und / oder Datenorientiert strukturieren. Technologische Strukturierung: Oft lassen sich Softwaresysteme meist in (G)UI, Kommunikation, Datenverarbeitung, Persistenz etc. gliedern. Topologische Strukturierung: Verteilte Systeme bestehen häufig aus Client und Server mit Middleware und Services. 2. Hauptaufgaben: Für jede Einheit wird im nächsten Schritt bestimmt, welche Art von Aufgaben für die jeweiligen Komponenten im Vordergrund stehen. Welche Arten von Aufgaben stehen für die eine Komponente im Vordergrund, z.B.: Neu zu entwickelnde (Teil‐)Systeme verlangen nach Analyse und System‐ und Architekturentwurf. Für sie ist auch eine passende Integrationsstrategie zu finden. Neu zu entwickelnde Komponenten erfordern I/F Design Programmentwurf, Implementation und Test. Vorbestehende Komponenten bzw. Teilsysteme müssen verstanden, adaptiert und integriert werden. (G)UI Komponenten müssen designed und ihre Usability muss sichergestellt werden. COTS müssen evaluiert, adaptiert und integriert werden. 3. Menschen & Prozesse: Formalisierungsgrad, Art und Anzahl der beteiligten Personen und Organisationen bestimmen wesentlich den Aufwand für PM, Doku, Schulung etc. Aufgrund der Menge und Art der Aufgaben kann einen geeignete Projektstruktur bestimmt werden. Es zeigt sich: ‐ ob und welche Teilprojekte gebildet werden können ‐ welchen Charakter (Neuentwicklung, Weiterentwicklung, …) das Projekt hat ‐ welche fachlichen und persönlichen Skills benötigt werden 15 | Chrösch 4. Aufwandschätzung (iterativ): Für alle Hauptaufgaben und unterstützenden Aktivitäten wird eine Grobschätzung des erwarteten Aufwands und der erwarteten Dauer vorgenommen. Für alle Projektaufgaben (Haupttätigkeiten und die unterstützenden Aktivitäten) wird eine Grobschätzung des erwarteten Aufwands – und falls dies eine unabängige Dimension ist – der erwarteten Dauer vorgenommen. Am besten ist es wenn die designierten Stakeholder eine Schätzung für ihren Zuständigkeitsbereich vornehmen, d.h.: ‐ Testing Verantwortlich für Test und Integration ‐ SW‐EntwicklerInnen für Detailentwurf, Implementation und Unittest ‐ Systemdesigner für System‐ und Architekturentwurf ‐ Projektleiter für Vorbereitungs‐, Übergangsphasen und unterstützende Aktivitäten Es ist anzustreben, dass jedes Element von wenigstens drei Personen geschätzt wird. Die entsprechenden Zahlen werden zusammengetragen und signifikante Unterschiede diskutiert. Hinter grösseren Differenzen stehen immer Missverständnisse und / oder unterschiedliche Basisannahmen. Nach dieser Iteration liegen die individuellen Schätzwerte für die einzelnen Projektaufgaben weniger als 15% auseinander. Diese Zahlen können nun z.B. nach der 3‐Punkt Methode aus PERT die Mittelwerte gebildet werden. Der so ermittelte Aufwand ist bei bekannter Umgebung (Applikation, Technologien, Personen) auf 5 bis 10% genau. Rollende Planung Makrozyklen: Die Projektaufgaben aus der Aufwandschätzung werden auf den Rahmenplan abgebildet (parallel / zeitversetzt / sequentiell) und zwar so, dass etwa zur Halbzeit ein Prototyp mit allen wesentlichen bzw. kritischen Elementen steht. (80‐20‐Regel) Mikrozyklen: Die aktuell anstehende Projektphase bzw. der aktuelle Makrozyklus wird in Mikrozyklen von beispielsweise jeweils zwei Wochen Dauer eingeteilt. Für diese Mikrozyklen macht man sich eine Tasklist und zwar wieder so, dass etwa zur Halbzeit (also z.B. nach einer Woche) allen wesentlichen bzw. kritischen Elementen stehen. (80‐20‐Regel) 16 | Chrösch Risiken Risiken identifizieren ‐ Systematik zur Risikoidentifikation der „Jäger und Sammler‐Ansatz“ liefert gerade aktuelle, nicht aber unbedingt die wichtigen Risiken. Projekte in gegebenem Umfeld haben immer ähnliche Risikoprofile. ‐> Risk Sources by Importance ‐ Bezug zu den Erfolgsfaktoren Risikoidentifikation soll einen klaren strategischen Bezug haben und sich auf die zentralen Erfolgsfaktoren – wie beispielsweise die Kernkompetenzen konzentrieren. ‐ Einsatz von Fachexperten Eine fundierte und objektive Risikoidentifikation erfordert möglicherweise den Einsatz von Fachleuten die unabhängig vom zu identifizierenden Risikobereich sind, aber das entsprechende Fach‐KnowHow haben. Die wichtigsten Risiken 1. Fehlendes Commitment des oberen Managements 2. Fehlendes Commitment beim Auftraggeber / Nutzer 3. Missverständnisse bei den Anforderungen 4. Unzureichender Einbezug von Auftraggeber bzw. Nutzer 5. Fehlendes Management der Endbenutzererwartungen 6. Fehlendes Change‐ & Scope‐Management Risiken analysieren ‐ Einheitliches Mass zur Bewertung eines Risikos verwenden. ‐ Objektive Daten verwenden, subjektiven Daten ohne nachvollziehbare Herleitung oder Begründung sind für Dritte nicht prüfbar. ‐ Sicher erwartete Entwicklungen stellen kein Risiko dar ‐> planen. ‐ Einmalige Schadenwirkung und anhaltende Wirkung unterscheiden. ‐ Schadenhöhe x Eintrittswahrscheinlichkeit ist nicht immer geeignet (z.B. können Absatzmengenrisiken, mit unterschiedlicher Wahrscheinlichkeit, einen Umfang von 1, 2, 3% usw. haben und sind besser durch eine Normalverteilung zu beschrieben) ‐ Risiken nicht überschneidend identifizieren ‐> „Doppelzählung“. ‐ „Kleinvieh macht auch Mist“: nicht auf katastrophenartige fixieren. ‐ Korrelationen und Wechselwirkungen im Gesamtkontext bewerten. Risikoanalyse (mittels geeigneter Massnahmen auf Risiken rechtzeitig reagieren) Vorgehen: 1. Beschreibung der Risiken und der nötigen Massnahmen zur Vermeidung/Eliminierung des Risikos erstellen. 2. Diese Risiken bewerten: Risiko [R = ExS] 3. Vermeidungskosten [V] beurteilen: (was kostet es ein Risiko zu vermeiden, eliminieren) 4. Berechnen der Umsetzungs‐Priorität: Gewicht [G] = R/V ‐> E*S/V (Massnahmen mit grösserem Gewicht werden zuerst umgesetzt). 17 | Chrösch Risiko‐Management und iteratives Vorgehen: In jedem iterativen Durchgang werden die jeweils grössten Risiken durch gezielte Massnahmen adressiert und systematisch eliminiert. Risiko‐Profil 18 | Chrösch 06 – Reviews: Konzept Reviews and Audits ‐ Reviews are public, verbal, interpersonal examinations of a program element. ‐> Product Quality ‐ An audit is an impersonal verification of tangible evidence of a process such as documentation. ‐> Process Quality Meilensteine ‐ Ein geplanter Punkt im Projektablauf an dem vorher festgelegte (Zwischen‐)Ergebnisse vorliegen, die es erlauben den Projektfortschritt zu messen. ‐ Zu jedem Meilenstein gehören Artefakte: Dokumente Software‐Komponenten Der Meilenstein ist erreicht, wenn die geforderten Artefakte vorliegen und ihre Überprüfung (Review/Test) erfolgreich war. Meilensteine im Projektverlauf Meilensteine werden meist aus übergeordneter Projektschicht festgelegt. Kunst ist es, diese mit den Iterationen/Phasen sinnvoll abzugleichen. Reviews und Meilensteine Typische Reviews: ‐ Feasibility Review (Systemabgrenzung und grober Projektplan) ‐ Requirements Review (Kundenanforderungen und Abnahmeplanung) ‐ Preliminary Design Review (Systemarchitektur und Testkonzept) ‐ Critical Desing Review (Detailentwürfe und UnitTest Spezifikationen) Vorgehen: Zeitliches Abgleichen von Meilensteinen und Reviews ‐ in „reinen“ Softwareprojekten fallen Review und Meilenstein meist zusammen. ‐ Ist Software nur ein Teil des Projektauftrags werden SW‐Reviews möglichst vor den Meilensteinen durchgeführt. ‐ Die Review Ergebnisse fliessen dann in den Meilenstein ein. Review Typen ‐ Inspection (rigorous well‐defined process) ‐ Team Review (planned and structured a bit less formal) ‐ Walkthrough (the author of a work product presents it to a group of peers) ‐ Pair Programming (two developers work on the same product simultaneously) ‐ Peer Deskcheck (only one person examines the work product) ‐ Passaround (deliver a copy to several people and collate their feedback) ‐ Ad Hoc Review (should be a natural part of team collaboration) 19 | Chrösch Review Activities What to Review ‐ Review dramatically reduce the rework required during product development. The goal is to catch potential problems early, before they contribute to cost increase, schedule slips, and lower product quality at delivery. ‐ Submit therefore all project artifacts like plans, requirements, designs, code etc. to a review. ‐ Select the most appropriate review method for a given situation based on risk: ‐ use inspections for high‐risk work products ‐ rely on cheaper techniques for other components Reviews in a Project Lifecycle ‐ Feasibility Review (sys.def. & proj.plan) ‐ Requirements Review (req.spec, user man., sys. & accept.test design) ‐ Prelim. Design Review (sys.design & integ.test specs) ‐ Critical Design Review (det. Design & unit test specs) ‐ Source Code Review ‐ Prod. Release Review Durchführung Cost of a Review Review Regularity and Duration ‐ Restrict team review sessions to one or two hours ‐ Review only one item or several small related items by one author at each session ‐ Because the review is tied to the stage in which the project is, schedule meetings when the respective item is ready. ‐ Higher lever elements especially benefit from reviews; these occur earlier, and the peer group might have to be drawn from outside the project. 20 | Chrösch Personal Dynamics ‐ The way in which the review is initiated is important: if A is the author and B the reviewer, ‐ you can’t say to B “I Want you to review A’s work.” This potentially sets up a conflict which will destroy the review’s objectives. ‐ Instead, say to A “Why don’t you talk the program over with B?” or “Have you discussed the program with B?” The first move must appear to come from the author and not the reviewer. ‐ Reviews are essentially an interpersonal affair; success depends on the personal dynamics between author and reviewers. ‐ be flexible with who reviews whose work: let the compatible pairs seek each other out. ‐ an ideal reviewer is not judgmental and recognizes that the primary benefit of a review is the act of “talking out” the program or unit. ‐ Potential or actual bugs caught in a review are still private relative to the element (e.g. unit, program, subsystem) and can therefore be handled privately. Team Review Process and Culture ‐ The participants receive the review materials several days prior to the meeting. ‐ It’s important that the team members are seriously preparing themselves i.e. to study the materials on their own. ‐ The review leader asks the participants if they hava any comments on a specific or page. ‐ The scribe captures issues as they’re raised, using standard forms the organization has adopted. ‐ It needs some discipline to abort the discussion after having discovered an error. ‐ Reviews and Walkthroughs have the positive side‐effect to promote a learning culture. Prepare For & Conduct Inspections 1. Build inspections into the project schedule ‐ plan to inspect all phases, starting with requirements ‐ allow for preparation (time consuming) & meeting time 2. Prepare for collection of inspection data ‐ include # defects per work unit (e.g. KLOC), time spent ‐ develop forms: include description, severity and type ‐ decide who, where, how to store and use the metric data default: appoint a single person to be responsible failure to decide usually results in discarding the data 3.Assign roles to participants ‐ Three adequate (author, moderator/recorder, reader) ‐ Two far better den none (author, inspector) 4. Ensure every participant prepares ‐ bring defects pre‐entered on forms to inspection meeting 21 | Chrösch 07 – Entwurfsmuster Einführung in Entwurfsmuster (Was sind Entwurfsmuster?) Entwurfsmuster ‐ Elemente wiederverwendbarer, objektorientierter Software ‐ Bewährte objektorientierte Entwürfe (Schablonen für ein wiederkehrendes Entwurfsproblem. ‐ Massgeblich entwickelt und popularisiert von Gang of Four (GoF) Wiederverwendung in der SW‐Entwicklung ‐ Wiederverwendung von bewahrten Entwurfsmustern als Ziel ‐ Verschiedene Arten von Wiederverwendung in der Softwareentwicklung: ‐ Objekte zur Laufzeit wiederverwenden ‐ Wiederverwendung von Quellcode / Klassen ‐ Wiederverwendung von einzelnen Komponenten ‐ Einsatz von Klassen‐Bibliotheken / Frameworks ‐ Wiederverwendung von Konzepten (z.B. Entwurfs‐, Architekturmuster) Wiederverwendung von Objekten ‐ Wiederverwendung von Objekten in einer Software (während Laufzeit) ‐ Beispiel: DB‐Connection in einem Connection‐Pool ‐ Effekt: bessere Performance, bessere Effizienz etc. ‐ Herausforderung: Verwaltung der Objekte, hier können Entwurfsmuster helfen Wiederverwendung von Quellcode/Klassen Wiederverwendung durch ‐ Copy&Paste (schlecht), Vererbung (meist schlecht) ‐ Aggregation und Komposition (gut) Effekte: ‐ geringerer Entwicklungsaufwand ‐ eher geringere Fehlerrate (Klassen bereits umfangreich getestet) Herausforderungen: ‐ Schnittstellen der Klassen eher fremdbestimmt ‐ Auswahl der geeigneten Klassenn/Bibliotheken ‐ etc. Wiederverwendung von Komponenten Beispiel: Logging‐Komponente, J2EE‐Beans, Corba‐Komponente etc. Effekte: ‐ geringerer Entwicklungsaufwand, weniger Fehler ‐ ganzheitlicher Ansatz, Blackbox, Abstraktion Herausforderungen: ‐ Anforderungen an die Umgebung/Kontext ‐ evt. inkompatible Schnittstelen ‐> Enwurfsmuster ‐ Komplexität in der Verwaltung ‐ etc. 22 | Chrösch Probleme der (Quellcode‐)Wiederverwendung Wiederverwendung ist sehr gut, bringt aber auch ein paar Probleme mit sich: ‐ unterschiedliche Kontexte / Fachverständnisse ‐ differente Technologien / Ansätze ‐ unterschiedliche Weiterentwicklung ‐ aufwändige Verwaltung (was wird wo eingesetzt) ‐ verschiedene Designkonzepte ‐ abhängig von Dritten Wiederverwendung von Quellcode ist und bleibt eine grosse Herausforderung Wiederverwendung von Konzepten ‐ Konzepte bleiben relativ konstant und stabil ‐ Zusätzlich relativ breit abgestützt und erprobt, weil weitgehend Sprach‐ und Implementationsunabhängig ‐ Die Wiederverwendung von bewährten Entwurfsmustern ist eine sehr elegante, wirkungsvolle, unproblematische und kostensparende Form von Wiederverwendung. ‐ Vergleiche: ‐ Kommunikationsmuster (z.B. Handshaking) ‐ Architekturmuster (z.B. C/S, Schichtung, MVC etc.) Gliederung der Entwurfsmuster (Welche Arten von Entwurfsmustern gibt es?) Klassifikation von Entwurfsmustern Entwurfsmuster werden primär nach Ihrem Zweck klassifiziert. Daraus sind drei Gruppen entstanden: ‐ Erzeugungsmuster (Creational Patterns) Abstrahieren die Erzeugung von Objekten ‐ Entscheidung welcher Typ ‐ zu welchem Zeitpunkt ‐ auf welche Art (Kontext, Konfiguration etc.) Delegation der Erzeugung an andere Objekte ‐ ‘Fabrik‘‐Konzept: Man fordert ein Objekt an Übersicht ‐ Abstrakte Fabrik (Abstract Factory, Kit) ‐ Erbauer (Builder) ‐ Fabrikmethode (Factory Method, Virtual Constructor) ‐ Prototyp (Prototype) ‐ Einzelstrück (Singleton) ‐ Strukturmuster (Structural Patterns) ‐ Fassaden Objekte (oder Klassen) zu grösseren/veränderten Strukturen zusammen ‐ Erlauben unterschiedliche Strukturen einander anzupassen und zu verbinden Übersicht ‐ Adapter (Adapter, Wrapper) ‐ Brücke (Bridge, Handle/Body) ‐ Dekorierer (Decorator, Wrapper) 23 | Chrösch ‐ Fassade (Facade) ‐ Fliegengewicht (Flyweight) ‐ Kompositum (Composite) ‐ Stellvertreter (Proxy, Surrogate) ‐ Verhaltensmuster (Behavioral Patterns) Beschreiben die Interaktion zwischen Objekten ‐ Legen die Kontrollflüsse zwischen den Objekten fest ‐ Zuständigkeit und/oder Kontrolle werden delegiert Übersicht ‐ Befehl (Kommando, Command, Action, Transaction) ‐ Beobachter (Observer, Dependents, Publish‐Subscribe, Listener) ‐ Besucher (Visitor) ‐ Interpreter (Interpreter) ‐ Iterator (Iterator, Cursor) ‐ Memento (Memento, Token) ‐ Plugin (Plugin) ‐ Schablonenmethode (Template Method) ‐ Strategie (Strategy, Policy) ‐ Vermittler (Mediator) ‐ Zustand (State, Objects for States) ‐ Zuständigkeitskette (Chain of Responsibility) Sekundär werden sie in Klassen‐ und Objektmuster unterteilt: ‐ Klassenmuster legen Beziehungen bereits zum Kompilierzeitpunkt fest ‐ die Beziehungen in Objektmustern zur Laufzeit sind dynamisch veränderbar ‐> IM SCRIPT HAT ES NOCH 3 BEISPIELE Einsatz von Entwurfsmustern (Wie setze ich Entwurfsmuster ein?) Voraussetzungen ‐ man muss die Entwurfsmuster kennen und verstehen ‐ Quellen: Literatur oder Internet Sinnvolle Auswahl und überlegter Einsatz ‐ Entwurfsmuster sind keine ultimative Lösung für alles ‐ Erfahrung sammeln, Erfahrung notwendig ‐ besser kein Muster einsetzen, als das Falsche Auswahl von Entwurfsmustern ‐ Es ist nicht immer einfach, das passende Muster (wenn überhaupt) auszuwählen ‐ Sinnvolles Vorgehen: ‐ Geht es um Erzeugung, Struktur oder Verhalten? Passende Muster mit gleicher Aufgabe vorselektieren ‐ Welche Vor‐ und Nachteile bieten die Muster? Bestes Muster auswählen (am meisten Vorteile, grösste Vereinfachung etc.) ‐ Bei Unterschieden: Wo haben Sie am meisten Variablen? Muster mit grösster Flexibilität auswählen (grösstes Potential bei Wartung) 24 | Chrösch Verifikation des Entscheides ‐ Nachdem man sich für ein Muster entschieden hat, sollte man unbedingt anhand von praktischen und fiktiven Beispielen verifizieren, ob die erhofften/erwünschten positiven Aspekte tatsächlich vorhanden sind. ‐ Beispiel anhand des Strategiemusters: ‐ Sind weitere, sinnvolle Algorithmen in Form von Strategien vorstellbar? ‐ Haben diese adäquaten Zugriff auf alle notwendigen Daten? ‐ Lässt sich die konkrete Strategie sinnvoll bestimmen bzw. konfigurieren? ‐ Wird das Resultat letztlich einfacher oder komplizierter? Variieren von Entwurfsmustern ‐ Auch wenn Entwurfsmuster wohlüberlegt und vielfältig erprobt sind, heisst das nicht, dass man sich stur daran halten muss ‐ Entwurfsmuster sind nur ein Konzept, welches auch wohlüberlegt verändert werden darf ‐ Sturheit in der Implementation kann ein Design auch komplizierter machen ‐ Eine unbedachte Veränderung kann die spätere Entwicklung behindern ‐ Erfahrung und Augenmass ist notwendig ‐> niemand behauptet SW‐Design ist einfach Kombination von Entwurfsmuster ‐ passiert relativ häufig, wird in der Literatur aber wenig erwähnt und erklärt ‐ eine Lösung lässt sich manchmal nur durch enge Kombination von Mustern erreichen ‐ Komplexität dadurch höher ‐ Muster treten nicht mehr in Reinform auf ‐> schwieriger als solche zu erkennen Beispiel: ‐ Fabrik für Zustände ‐ Fassade für Fabriken von dekorierten Strategien ‐> IM SCRIPT HAT ES NOCH 2 BEISPIELE Zusammenfassung Relativ grosse Zahl an Entwurfsmuster verfügbar (20+) ‐ für verschiedene Zwecke / Problemlösungen ‐ weitgehend sprachenunabhängig ‐ gut und ausführlich dokumentiert ‐ Rad muss nicht immer neu erfunden werden Nicht für alles gibt es ein Entwurfsmuster das passt ‐ Entwurfsmuster sind kein goldener Hammer ‐ Auswahl des geeigneten Musters ist nicht immer einfach ‐ erzwungener Einsatz geht meistens schief ‐ manchmal muss man Kombination von Mustern anwenden 25 | Chrösch 08 – Testing: Einführung (Grundlagen zu Software‐Testing) Bei vielen Entwickler verpönt und unbeliebt. Warum? ‐ Ich kann programmieren, ich mache keine Fehler ‐ Ich will programmieren, nicht testen ‐ Ich muss den Termin einhalten, es muss schon fertig sein Testen hat leider noch vielerorts ein schlechtes Image und ist uncool ‐ einerseits in einzelnen Köpfen (Entwickler) ‐ andererseits aber auch in der Firmenkultur Aber: Tests gewährleisten, dass Software möglichst fehlerfrei arbeitet ‐ Software steuert medizinische Geräte im Spital (Herz‐/Kreislaufmaschine, …) ‐ Software steuert und kontrolliert Verkehrsmittel (Luftraumüberwachung, Autopilot) ‐ Software steuert aufwändige und komplizierte Prozesse (Sicherheit, Industrie, …) Motivation fürs Testen (Warum testen von Software Spass macht!) ‐ Nicht: Wir testen nur um Fehler zu finden! ‐ Sondern: Wir testen kontinuierlich schon während der Implementation, um von Anfang an die Bestätigung zu haben, dass es funktioniert. ‐ Fehler finden bevor man sie gemacht hat. ‐ Fehler korrigieren bevor man sie impelemntiert hat. ‐ Fehler schon im Ansatz (wenn es noch niemand anders gemerkt hat) finden. ‐ Test‐First Ansatz Testarten Überblick Integrationstest, Systemtest ‐ Integration: Integration der Komponente/des Systems in die bestehende Software ‐ Kompatibilität, fehlerfreie Installation, Performance ‐> technische Sicht ‐ System: Testen eines gesamten Systems auf Basis der Spezifikation ‐ fachliche Korrektheit, Usability etc. ‐> eher Benutzersicht ‐ Tests müssen explizit in einer Phase geplant, organisiert und durchgeführt werden ‐ z.T. beträchtlicher Aufwand für Testumgebung: Bereitstellung und Konfiguration der Umsysteme, von Testdaten etc. Nutzen ‐ Positiv: ‐ in komplexen Systemen fundamental für eine erfolgreiche Einführung ‐ meist gut etabliert und akzeptiert ‐ interdisziplinäre Zusammenarbeit (Informatik mit Fach) ‐ Negativ: ‐ relativ grosser Aufwand ‐ Fehler werden erst spät aufgedeckt ‐ Fehlerbehebung ist aufwändig und teuer Unit‐Test ‐ Häufig mit Komponenten‐, Modul‐ und Entwicklertest gleichgesetzt ‐ funktionaler Test von einzelnen, in sich abgeschlossenen Units (Klassen, Modulen) 26 | Chrösch ‐ Ziel: ‐ schnelle, einfache auszuführende, automatisierte Tests ‐ ohne Abhängigkeiten von Umsystemen ‐ werden während der Entwicklung ausgeführt innerhalb der Entwicklungsumgebung (DIE) innerhalb des Buildprozesses ‐ Unterstützung durch Frameworks (z.B. JUnit) Nutzen ‐ Positiv: ‐ neue oder veränderte Komponenten können schnell getestet werden ‐ Testen vollständig in die Implementationsphase integriert ‐ Test‐First Ansatz möglich ‐ automatisiertes, übersichtliches Feedback / Reporting ‐ Integration von Coverage‐Messungen möglich ‐ Negativ: ‐ für GUI(‐Komponenten) schwieriger durchführbar ‐ Qualität und Nachvollziehbarkeit der Testfälle muss überprüft werden ‐ Bilanz: ‐ Nutzen unbestritten ‐ Qualität abhängig von Entwickler ‐ Unterstützung durch Frameworks in nahezu jeder Sprache und Umgebung ‐ Aber: Es wird meist gespart, was sich später sehr stark rächen kann. Test‐First‐Methode ‐ Entwickelt aus XP (extrem programming) ‐ Vor der Implementation immer zuerst die Testfälle schrieben Vorteile: ‐ Während dem schrieben der Testfälle denkt man unmittelbar auch an die Implementation des zu testenden Codes. Dabei reift diese buchstäblich heran. ‐ Typisch fallen einem dabei viele Ausnahmen und Sonderfälle ein, welche man bei der Implementation der eigentlichen Komponenten dann auch berücksichtigt. ‐ Kaum ist die Komponente fertig, kann sie sofort getestet werden ‐ sehr einfacher, aber genialer Ansatz ‐ basiert technisch auf Unit‐Tests ‐ arbeitet problemlos mit bewährten Unittest‐Werkzeugen zusammen ‐ Einziger Haken: Man muss es machen Code Coverage Messung der Codeabdeckung von Tests ‐ Problem: Wie kann man die Qualität von Unit‐Tests beurteilen und verbessern? ‐ Ziel: Mit möglichst geringem Aufwand einen umfassenden Testfall implementieren. ‐ Lösung: Messen der Codeabdeckung von Testfällen ‐ während dem Testdurchlauf wird von der Laufzeitumgebung gemessen welche Codezeilen tatsächlich abgearbeitet werden ‐ statische Aufbereitung der Daten 27 | Chrösch nach Testfall, Komponente, Package, Teilsystem etc. z.T. auch historisiert, d.h. zeitliche Entwicklung der Werte Was ist Code Coverage? ‐ Code Coverage ist eine Metrik welche zur Laufzeit misst, welche Quellcodezeilen abgearbeitet wurden. ‐ Diese Messung wird typisch mittels Unit‐Testfälle (z.B. mit JUnit) durchgeführt. ‐ Somit kann eine Aussage gemacht werden, wie umfassend der Code getestet wurde: ‐ Verbesserung der SW‐Qualität durch bessere Qualität der Testfällse ‐ Effizienzsteigerung der Testfälle Was wird gemessen? Man unterscheidet verschiedene Messtechniken: Statement Coverage (Line Coverage) ‐ Misst ob und wie häufig eine einzelne Codezeile durchlaufen wurde. ‐ Problem: ‐ Wird bei der Zeile logisch verglichen, ist ein einmaliger Durchlauf nicht repräsentativ Decision Coverage (Branch Coverage) ‐ Bei Fallunterscheidungen (if, while etc.) wird zusätzlich geprüft, dass beide Fälle (true und false) aufgetreten sind Path Coverage ‐ es wird gemessen, ob alle möglichen Kombinationen von Programmablaufpfäden durchlaufen wurden ‐ Problem: Die Anzahl der Möglichkeiten steigt exponential mit der Anzahl Entscheidungen Function Coverage ‐ Misst auf der Basis der Funktionen, ob sie aufgerufen wurden. Race Coverage ‐ Konzentriert sich auf Codestellen die parallel ablaufen. ‐ Unterschiedlich aufändig und aussagekräftig ‐ Die meisten Code Coverage‐Werkzeuge auf dem Markt unterstützen nur Statemen‐ und Decision‐Coverage, teilweise noch Path Coverage. ‐ Dennoch liefern sie damit schon sehr wertvolle Aussagen: ‐ Codeteile die beim Test schlicht vergessen wurden ‐ Ausnahmen, die nicht berücksichtigt wurden Funktionsweise ‐ Instrumentierung des Quellcodes Der Quellcode wird durch einen Preprocessor vor dem Compilieren mit Statements zu Coverage‐Messung ergänzt. ‐ Instrumentierung des Bytecodes Der Bytecode wird bei der Compilierung (modifizierter Compiler), oder unmittelbar danach von einem Postprocessor mit Bytecode zur Coverage‐Messung ergänzt. ‐ Modifizierte VM (im Falle von Java) Instrumentalisiert der Bytecode unmittelbar bei dessen Ausführung. 28 | Chrösch Nachteile der Code Coverage Messung ‐ Instrumentierter Code ist langsamer ‐ nicht geeignet für zeitkritische Systeme ‐ Instrumentierter Code muss gesondert behandelt werden ‐ darf/sollte nicht in die produktive Distribution/Deployment gelangen ‐ Ausschliesslich für die Ausführung der Testfälle Auswertung/Integration Generierung von Reports (HTML) ‐ Bequem, wird von den meisten Produkten unterstützt. ‐ Kann problemlos automatisiert werden (Build‐Process) Analyse mittels freistehender Anwendung ‐ Erweiterte Funktionalität, Verlinkung etc. ‐ Für interaktive Detailanalyse Integration in Entwicklungsumgebung ‐ praktisch während der unmittelbaren Entwicklung von Testfällen Herausforderungen ‐ Eine 100%‐ige Abdeckung ist eine Illusion ‐ Erreichbare Abdeckung stark abhängig von Projekttyp ‐ Automatisierbare Testfälle als Grundlage ‐ Exceptionhandling ist eine Herausforderung ‐ Realistische Werte liegen im Bereich von 40‐70% ‐ Projektspezifisch festlegen ‐ Kann im Build‐Prozess automatisch geprüft werden Testen – weitere Möglichkeiten Software‐Metriken zur Identifikation von ‐ grossen Methoden, fetten Klassen, tiefen Vererbungen etc. ‐ komplexen und somit fehleranfälligen Quellcodestellen ‐ können in Testfälle eingebaut werden ‐> Fehler wenn Grenzwerte überschritten Profiling / Performance und Memory ‐ Messen des Zeit‐ und Memorybedarfs einer Anwendung/Komponente ‐ Welche Methoden benötigen am meisten Laufzeit? ‐ Welche Algorithmen benötigen viel Memory? ‐ Wo sind evt. Memory‐Leaks? Mocking ‐ Mock Objects erlauben Simulation von komplexen Umsystemen mittels Stubs ‐ Mock Objects an der Stelle der echten Objekte ‐ enthalten minimale Logik um übergebende Parameter zu validieren ‐ Unterstützung durch verschiedene Frameworks FitNesse ‐ Testing Framework kombiniert mit Wiki und Collaboration ‐ Testdaten in Wiki dynamisch erfassen und erweitern ‐ Testweise fachtauglich, sprich für fachliche Testerinnen Continous Builds und Continous Integration ‐ ebenfalls aus dem XP‐Ansatz entstanden ‐ Buildserver welche dauernd das gesamte Projekt builden und Testfälle ausführen ‐ Builds bei Änderungen im SCM‐Tool (cvs, svn etc.) 29 | Chrösch ‐ regelmässige Builds (z.B. Nightly‐Build) ‐ manuell ausgelöste Builds ‐ Aufbereitung detaillierter Statistiken und Metriken ‐ Durchführung von umfangreicheren Testfällen ‐ mehr Ressourcen zur Verfügung Zusammenfassung ‐ Nicht nachträgliches Testen zur Fehlerursache, sondern kontinuierliches Testen zur Bestätigung dass es funktioniert ‐ Test‐First‐Ansatz als sehr attraktive Methode aus dem XP‐Ansatz ‐ Unterstützung durch zahlreiche Werkzeuge, Frameworks, Plugins etc. ‐ Vollständige Integration der Unit‐Test in die Implementierungsphase ‐ Messung der Code Coverage als Motivationsfaktor ‐ Testen macht spass 30 | Chrösch 09 – Modularisierung: Module‐Konzept Modul‐Begriff ‐ Ein in sich abgeschlossener Teil des gesamten Programm‐Codes, bestehend aus einer Folge von Verarbeitungsschritten und Datenstrukturen. ‐ Die Anwendung des Modulkonzepts im Software Engineering wurde bereits 1972 von David Parnas publiziert. Kopplung und Kohäsion Kopplung (Coupling): Ausmass der Kommunikation zwischen Modulen. Unabhängigkeit der einzelnen Module. ‐> Minimiere die Kopplung! Kohäsion (Cohesion): Ausmass der Kommunikation innerhalb eines Moduls. Interner Zusammenhalt des Moduls ‐> Maximiere die Kohäsion! Wichtige Kriterien des modularen Entwurfs 1. Zerlegbarkeit Teilprobleme sind unabhängig voneinander entwerfbar 2. Kombinierbarkeit Module sind unabhängig voneinander (wieder‐)verwendbar 3. Verständlichkeit Module sind unabhängig voneinander zu verstehen 4. Stetigkeit kleine Änderungen der Spezifikation führen nur zu kleinen Änderungen im Code Arten von Modulen ‐ Bibliotheken Sammlung von oft benötigten und thematisch zusammengehörenden Funktionen. 31 | Chrösch ‐ abstrakte Datentypen ein Modul implementiert einen neuen Datentyp und stellt die darauf definierten Operationen zur Verfügung. ‐ Modellierung physischer Systeme insbesondere in technischen Anwendungen der Informatik z.B. Sensorsystem‐Modul ‐ Modellierung logisch‐konzeptionelle Systeme logisch‐konzeptionelle Systeme modellieren und für andere Komponenten auf hoher Abstraktion nutzbar machen. Zerlegbarkeit – modular decomposability ‐ Zerlege ein Softwareproblem in eine Anzahl weniger komplexe Teilprobleme und verknüpfe diese so, dass die Teile möglichst unabhängig voneinander bearbeitet werden können. ‐ Die Zerlegung wird häufig rekursiv angewendet: Teilprobleme können so komplex sein, dass sich eine weitere Zerlegung aufdrängt. Kombinierbarkeit – modular composability ‐ Strebe möglichst frei kombinierbare Software‐Elemente an, die sich auch in einem anderen Umfeld wieder einsetzen lassen. ‐ Kombinierbarkeit und Zerlegbarkeit sind voneinander unabhängige Eigenschaften Verständlichkeit – modular understandability ‐ Der SourceCode eines Moduls soll ach verstehbar sein ohne dass man die anderen Module des Systems kennt. ‐ Software‐Unterhalt setzt voraus, dass die Teile eines Systems unabhängig von einander zu verstehen und zu warten sind. Stetigkeit – modular continuity ‐ Von einer kleinen Änderung der Anforderungen soll auch nur ein kleiner Teil der Module betroffen sein. ‐ Es ist oft unvermeidlich, dass sich im Laufe eines Projektes die Anforderungen ändern. Stetigkeit bedeutet, dass dies nicht die ganze Systemstruktur beeinflusst, sondern sich lediglich auf einzelne Module auswirkt. Prinzipien des modularen Entwurfs ‐ lose Kopplung schmale Schnittstellen: nur das wirklich Benötigte austauschen ‐ starke Kohäsion hoher Zusammenhalt innerhalb eines Moduls ‐ Information Hiding Modul ist nach aussen nur über seine Schnittstelle bekannt ‐ wenige Schnittstellen zentrale Struktur ‐> minimale Anzahl Schnittstellen (Aufrufe, Daten) ‐ explizite Schnittstellen Aufrufe und gemeinsam genutzte Daten sind im Code ersichtlich 32 | Chrösch Layers, Tiers & Packages Layers ‐> use‐Beziehung ‐ Öffentliche Methoden in Layer B dürfen von der Software in Layer A genutzt werden. ‐ Man spricht von einer use‐Beziehung wenn das korrekte Funktionieren von A von einer korrekten Implementation von B abhängt. Keine Layer Layer‐Beziehungen ‐ Eine Klasse P0 kann eine use‐Beziehung mit der Klasse P1 haben ohne P1 aufzurufen. z.B. kann P0 davon abhängig sein, dass P1 ein gemeinsam benutztes Device initialisiert hat ‐ Eine Klasse P1 kann P2 aufrufen ohne eine use‐Beziehung mit P2 zu haben: ‐ P2 sei ein Errorhandler, dessen Name an P1 via einen Nameserver übergeben wird ‐ P1 ruft P2 wenn P1 einen Fehler entdeckt, kümmert sich aber nicht was P2 tut Tiers In einer n‐Tier Client‐Server Architektur werden Layers häufig mit Tiers verwechselt: 33 | Chrösch 10 – Reviewdurchführung: Rollen und Unterlagen beim Review Ablauf einer Peer‐Review ‐ Genügend Zeit einplanen und Unterlagen rechtzeitig verteilen, damit die Gutachter den Prüfling auch wirklich anhand der Referenzunterlagen analysieren können. ‐ In der Sitzung nur Kritikpunkte aufnehmen ‐> Protokoll (Verständnisfragen sind erlaubt). ‐ Diskussionen bilateral ausserhalb der Sitzung „dritte Stunde“. ‐ Nacharbeit auf Basis des Protokolls in Eigenverantwortung. Protokoll 34 | Chrösch 11 – UML Sequenzdiagramme: oder 35 | Chrösch 11|12|13|14 – Komponentenarchitektur: Client Server Computing Middelware‐Modelle ‐ Alles ist ein File Files sind lokal oder remote, alle können darauf zugreifen ‐ Verteiltes Filesystem Transparenz nur für traditionelle Files (nicht für Starten von Prozessen usw.), benützt Fileservices des Netzwerk‐Betriebssystems. ‐ Remote Procedure Call Netzwerkkommunikation ist verborgen, ein Prozeduraufruf wird durch einen Remote Server ausgeführt ‐ Verteilte Objekte Methoden eines entfernten Objektes können aufgerufen werden, nur die Schnittstelle muss bekannt sein Client‐Server Modell ‐ Client‐Server Zusammenarbeitsprinzip: Server bietet Dienstleitungen an, die von Clients angefragt resp. in Anspruch genommen werden. ‐ Die Kommunikation zwischen Client und Server kann einfach und verbindungslos oder verlässlich ablaufen. Verteilte Systeme Ein verteiltes System ist eine Ansammlung von unabhängigen Rechnern, die sich dem Benutzer gegenüber als ein kohärentes System präsentieren. Client/Server ‐ verschiedene Prozesse ‐ Client: Dienstbenutzer ‐ Server: Diensterbringer ‐ Dienst nach ISO/OSI Charakteristiken von Client/Server ‐ Erbringung eines Dienstes ‐ geteilte Ressourcen ‐ asymmetrische Protokolle ‐ Transparenz der Lokalität 36 | Chrösch ‐ heterogene Systeme ‐ nachrichtenbasierte Kommunikation ‐ Verkapselung von Diensten ‐ Skalierbarkeit ‐ Integrität Fat Client und Fat Server Modell Vom 2‐Tier zum 3‐Tier Client/Server N‐Tier Client/Server Middleware ‐ lässt Client einen Dienst vom Server erhalten ‐ umfasst Übertragung der Anfrage sowie der Antwort ‐ erbrachte Dienst und das User Interface gehören nicht mehr zur Middleware ‐ Middleware ermöglicht einer Anwendung ‐Anwendungen und Dienste transparent zu lokalisieren ‐ mit Anwendungen und Diensten zu interagieren ‐ unabhängig von einzelnen Netzwerkdiensten zu sein ‐ zuverlässig und verfügbar zu sein ‐ aufwärtsskalierbar ohne Funktionsverlust zu sein Middleware in N‐Tier ‐ Bereitstellung der Plattform, um Server‐Komponenten laufen zu lassen ‐ Sicherstellen der Integrität von Transaktionen ‐ Bereitstellung einer hohen Verfügbarkeit ‐ Sicherung der Umgebung 37 | Chrösch Verteilte Objekte und Komponenten Definition: Verteiltes Objekt ‐ Ein Objekt ist eine verkapselte Software Einheit, die einen Zustand (Daten) und ein Verhalten (Methoden) enthält. ‐ Ein verteiltes Objekt ist ein Objekt, auf das entfernt zugegriffen werden kann. Definition des Komponentenbegriffs ‐ Aus dem lateinischen componere (zusammensetzen) ‐ Eine Software‐Komponente ist ein Software‐Element, das zu einem bestimmten Komponentenmodell passt und entsprechend einem Composition Standard ohne Änderungen mit anderen Komponenten verknüpft und ausgeführt werden kann. Eigenschaften von Komponenten selbstbeschreibend Lebenszyklusmanagement erzeugt Events Transaktionskontrolle konfigurierbar Dauerhaftigkeit des Zustands systemunabhängige Softwareeinheit Beziehungsmanagement Sicherheit Self‐Testing Licensing Semantisches Messaging Versionskontrolle Kommunikation ‐ (Interprozess‐)Kommunikation (Interprocess Communication, IPC) bedeutet einen Austausch von Informationen zwischen kooperierenden parallelen Prozessen. Häufig werden dazu Nachrichten (Botschaften, messages) benutzt (nachrichtenbasierte Synchronisation). ‐ Kommunikation kann synchron oder asynchron erfolgen. Beim synchronen Austausch müssen alle Beteiligten zur gleichen Zeit an der Kommunikation mitwirken (Beispiel: Konferenzsystem); bei asynchroner Kommunikation wird die Information zwischengespeichert und später bearbeitet. UML Sequenzdiagramme ‐ Beschreibung einzelner Abläufe zwischen Objekten und Aktoren in ihrer chronologischen Reihenfolge ‐ Zwei Dimensionen: vertikal ‐> Zeit horizontal ‐> Objekte und Interaktionen ‐ Lebenslinie: Vertikale, gestrichelte Linie, welche die Lebensdauer eines Objektes darstellt. x ‐> Objekt wird gelöscht 38 | Chrösch ‐ Spezielles Objekt Aktor: stösst Ablauf an Notation Einsatz ‐ Ausgangslage: Objekte sind bereits definiert ‐ dynamische Analyse von Use Cases ‐ zeitliche Abläufe noch unklar oder zu verifizieren ‐ Einsatz in Analyse und Design Die verschiedenen Middleware – Ansätze Remote Procedure Call (RPC) ‐ Middleware zur Implementation verteilter Anwendungen ‐ baut auf der Semantik von Prozeduraufrufen auf ‐ im Client wird der Dienst genauso aufgerufen wie eine lokale Prozedur/lokale Funktion Zentrale Idee: Schnittstellte ‐ Mit einer Schnittstelle beschreibt man den Dienst: den Namen der Prozedur, die Parameter und den Rückgabewert. ‐ Eine Schnittstelle entspricht einem „Vertrag“ zwischen Client und Server. ‐ Wenn man die Schnittstelle kennt, weiss man auch, wie die Nachrichten zwischen Client und Server aussehen: ‐ welche Informationen sie erhalten ‐ wie diese Informationen kodiert werden müssen ‐> Möglichkeit einer automatischen Erzeugung von Code, der die Kommunikation unterstütz! IDL 39 | Chrösch ‐ IDL Compiler: erzeugt den Client Stub, den Server Stub automatisch basierend auf einer Beschreibung in der IDL ‐ Stub im Client: adressiert die Nachrichten an den Server | verpackt die Parameterwerte in die Nachricht | sendet die Nachricht an den Server | verarbeitet die Nachricht (Antwort) vom Server ‐ RPC Run Time: stellt Laufzeitumgebung und Infrastruktur zur Verfügung ‐ Stub im Server: entpackt die Nachricht vom Client | ruft die Funktion/Prozedur auf | sendet Antwort an den Client zurück RPC: Fehlersemantik ‐ der Client kann ausfallen, nachdem er eine Anforderung geschickt hat ‐ der Server kann ausfallen; bevor, während, nachdem er eine Anforderung bearbeitet hat ‐ Nachrichten können verloren gehen Fehlersemantiken Maybe Semantik: ‐ man ignoriert die Fehlerfälle und trifft keine Vorkehrungen ‐ wenn alles gut geht, wird die Prozedur genau einmal ausgeführt und erhält der Client genau eine Antwort ‐ wenn Fehler auftreten, wurde die Prozedur einmal oder keinmal ausgeführt, Client erhält Antwort oder nicht ‐ keine Garantien ‐ best effort ‐ günstig (kein Verwaltungsaufwand) At‐least‐once Semantik: ‐ Garantie: Prozedur wird mindestens einmal ausgeführt ‐ Client setzt nach Aufforderung einen Timer ‐ erhält er keine Antwort, wird die Prozedur noch einmal aufgerufen ‐ evtl. wird Prozedur mehrfach ausgeführt, evtl. erhält Client die Antwort mehrmals ‐ die Prozedur darf nicht zu Zustandsänderungen führen ‐ Garantie gilt bei Nachrichtenverlust ‐ keinerlei Aussagen, wenn Server ausfällt At‐most‐once Semantik: ‐ Garantie: Prozedur wird im Server höchstens einmal ausgeführt ‐ Garantie gilt, wenn Nachrichten verloren gehen und wenn der Server ausfällt ‐ sofern nur Nachrichtenverluste vorliegen: die Prozedur wird genau einmal ausgeführt und ein Ergebnis wird im Client verarbeitet ‐ komplexes Protokoll: Numerierung und Pufferung von Nachrichten Exactly‐one Semantik: ‐ Garantie: sowohl bei Nachrichtenverlusten als auch bei Serverausfall wird die Prozedur in jedem Fall genau einmal ausgeführt 40 | Chrösch ‐ Kombination der verschiedenen Möglichkeiten ‐ teuerste Semantik Infrastruktur für RPCs Anforderungen: ‐ Auffinden des Servers ‐ automatisches Starten der Serverprozesse ‐ automatisches Beenden der Serverprozesse ‐ Priorisierung von Anfragen ‐ Sicherheitsüberprüfungen (insbesondere auch Authentifizierung und Autorisierung) ‐ Load‐balancing RPC Binding ‐ Beziehung zwischen einem Client und einem Server ‐ dynamisches Binden: Client verwendet einen Directory Dienst, um den Server zu finden ‐ automatisches Binden: der Client Stub lokalisiert den Server ‐ Wie kann der Server lokalisiert werden? ‐ Information ist im Clientcode hart codiert ‐ Information ist in einer Konfigurationsdatei oder in einer Umgebungsvariable ‐ Anfragen beim Network Directory Service ‐ Unterstützung von RPC durch das NOS (Netwerkbetriebssystem) Remote Methode Invocation (RMI) ‐ Java Sprachelement (ab JDK Version 1.1) ‐ setzt Prinzip des RPC um ‐ benötigt keine IDL sondern verwendet Java zur Beschreibung des Interfaces ‐ Jedes verteilte Objekt muss das Interface Remote implementieren und jede zur Verfügung gestellte Methode kann die Exception RemoteException auslösen. ‐ Nach Start muss das Objekt (der Dienst) im Registry eingetragen werden. Message Orientet Middleware (MOM) ‐ ist eine Middleware 41 | Chrösch ‐ unterstützt die Implementation von verteilten Anwendungen ‐ geeignet bei: ‐ Toleranz in Bezug auf Antwortzeiten ‐ nomadic computing ‐ Austausch von nicht‐spezifischen Nachrichten mittels Warteschlangen (Queues) ‐ Client und Server kommunizieren über Nachrichten, die in einer Queue abgelegt werden ‐ es existiert keine direkte Verbindung ‐ Client und Server müssen nicht gleichzeitig aktiv sein ‐ keine Anforderungen an die Struktur der Kommunikation: ‐ request/reply ‐ request Infrastruktur MOM Produkte müssen Elemente eines Netzwerkbetriebsystems spezifizieren, um Anwendungen zu unterstützen: ‐ hierarchische Namensgebung ‐ Sicherheitsmechanismen ‐ Schicht, um Anwendungen vom Netzwerk zu isolieren Flexibilität ‐ Spezifikation einer Antwort Queue ‐ Nachrichten können unterschiedliche Formate haben (ist nicht spezifiziert); format field ‐ keine zeitlichen Einschränkungen, Nachricht wird gelesen, wenn der Empfänger möchte ‐ Sender und Empfänger zeitlich entkoppelt ‐ Client wird nicht blockiert bis Server geantwortet hat ‐ Auslieferung von Nachrichten kann garantiert werden Einsatz von Message Queues ‐ one‐to‐many Beziehung ‐ many‐to‐one Beziehung ‐ Message Filter, um Messages zu ignorieren oder weiterzuleiten Eigenschaften von Queues ‐ persistent oder nicht persistent ‐ kopierender oder entfernender lesender Zugriff ‐ lokal oder entfernt ‐ i.d.R. kann die max. Anzahl Nachrichten, max. Grösse definiert werden ‐ transactional queues Bewertung ‐ wird seit vielen Jahren eingesetzt, stabile und robuste Produkte ‐ vielseitig einsetzbar ‐ keine zugrundeliegenden Standards; mit Entscheidung für ein Produkt legt man sich auf Dauer fest 42 | Chrösch ‐ Kommunikationscode ist in Client und Server zu implementieren ‐ neue Entwicklungen: selbstbeschreibende Nachrichten, verbesserte Namenssysteme, grosse Nachrichten Vergleich: MOM vs. RPC CORBA IDL ‐ IDL = Interface Definition Language ‐ sie ist rein deklarativ ‐ die mit IDL spezifizierten Methoden lassen sich in jeder Sprache, die CORBA unterstützt, schrieben und aufrufen ‐ Ziel: alle Client/Server Middleware und alle Komponenten zu „IDLisieren“ ‐ muss Komponenten so spezifizieren, dass die Implementierung als Black Box betrachtet werden kann, von ‐ Run‐Time Clients, die das Objekt verwenden wollen ‐ Entwicklern, die eine ex. Funktion einer Komponente mit Unterklassen erweitern ‐ kann verwendet werden, um … zu definieren ‐ Attribute ‐ Klassen, von denen geerbt wird ‐ Ausnahmebedingungen (exceptions) ‐ Ereignisse (events) ‐ Methoden (einschliesslich Input und Output Parameter und deren Datentypen) Datentypen in CORBA ‐ einfach: short, long, long long, unsigned short, unsigned long, unsigned long long, float, double, long double, char, Boolean, octet, string, enum, any ‐ konstruiert: struct, array, union, sequence ‐ objektreferenzen 43 | Chrösch Das Modul ‐ entspricht einem Namensraum ‐ enthält eine oder mehrere Klassendefinitionen (interface) ‐ die Modulvereinbarungen (Typ, Ausnahmen, Konstanten) gelten für alle Interfaces des Moduls. Das Interface Das Attribut ‐ es existieren 2 Arten von Attributen: ‐ ‐ Der Parameter ‐ call‐by‐value <‐> call‐by‐reference ‐ Richtung: in | out | inout ‐ 44 | Chrösch Die Methode ‐ Name der Methode ‐ Rückgabewert der Methode ‐ Parameter der Methode ‐ Ausnahmen (exceptions) der Methode ‐ Kontext der Methode ‐ oneway und andere Methoden Eine erste CORBA Anwendung Object Request Broker (ORB) ‐ Ein ORB ist die Middleware Technologie, welche die Kommunikation und den Datenaustausch zwischen Objekten ermöglicht. Objekte und deren Funktionalität sind von der Kommunikation der Objekte völlig getrennt. ‐ Funktionalität eines ORBs: ‐ Definition von Schnittstellen ‐ Lokalisierung und Aktivierung von entfernten Objekten ‐ Kommunikation von Clients und Objekten Idee eines ORB Transparenz ‐ ORB vermittelt die Illusion, als wären alle Objekte am selben Ort wie der Client ‐ verschiedene Arten von Transparenz: ‐ Programmiersprache ‐ Betriebssystem ‐ Host Hardware ‐ Lokalität Realisierung des ORB Konzeptes ‐ Einbindung von ORB Funktionalität in Clients ‐ Implementation in separaten Prozessen ‐ Implementation als Teil des Betriebssystemkernels CORBA (Common Object Request Broker Architecture) ‐ Common Object Request Broker Architecture ‐ OMG (Object Management Group): über 700 Vertreter aus Industrie und Forschung ‐ offener “Bus” 45 | Chrösch Eigenschaften eines CORBA ORBs ‐ statische und dynamische Methodenaufrufe (strenge Typüberprüfung <‐> maximale Flexibilität) ‐ Verknüpfungen auf Hochsprachenebene (auch über Sprachgrenzen hinweg) ‐ selbstbeschreibendes System ‐ Ortstransparenz ‐ eingebaute Sicherheit und Transaktionen ‐ polymorphe Nachrichten (derselbe Funktionsaufruf kann je nach Objekt verschiedene Effekte haben) ‐ Koexistenz mit eixistierenden Systemen Ablauf eines CORBA Methodenaufrufs ‐ Der Client muss wissen, wie das Objekt aussieht und welche Methoden es hat. Interface Repository ‐ Der Client muss das Objekt mit Hilfe des ORB finden können. Namensdienst 46 | Chrösch ‐ Der Client muss einen Methodenaufruf generieren. ‐ Der Methodenaufruf muss vom Client zum CORBA Objekt weitergeleitet werden. CORBA ORB Core ‐ Der Server muss dafür sorgen, dass das CORBA Objekt aktiv ist und Anfragen entgegen nehmen kann. Object Adapter ‐ Das CORBA Objekt muss die Methode ausführen und allfällige Werte zurückgeben. ‐ Der Client muss davon in Kenntnis gesetzt werden, dass die Methoden beendet wird, er erhält aufgetretene Ausnahmen, Rückgabeparameter und Rückgabewerte. Der „eigentliche“ ORB Der Client erhält eine Objektreferenz ‐ Mit Hilfe verschiedener Dienste (insbesondere Namensdienst) und des ORB erhält der Client eine Referenz auf das CORBA Objekt. ‐ Mit Hilfe dieser Referenz ruft der Client eine Methode im CORBA Objekt auf. Der Client Stub ‐ Verpackt den Methodenaufruf in eine Nachricht ‐ Marshalling Der Object Adapter ‐ aktiviert und deaktiviert die Objektimplementation ‐ Server ist der Ausführungsort des Objektes ‐ die Implementation wird gegebenenfalls auf dem Implementation Repository geholt 47 | Chrösch Der Server Skeleton ‐ der Skeleton entpackt die Nachricht vom Client und ruft die Methode auf ‐ nach Methodenaufruf generiert der Skeleton eine Nachricht mit Rückgabewerten und Ausnahmen an den Client Erstellung einer CORBA C/S Anwendung ‐ erzeuge das Objekt Interface mit IDL ‐ übersetze die IDL Datei ‐ implementiere das Objekt ‐ implementiere den Server ‐ trage Objekt in Implementation Repository ein ‐ implementiere den Client 48 | Chrösch Object Adapter, Servants und CORBA Objekte Einleitung ‐ es gibt möglicherweise 1000‐de von CORBA Objekte ‐ zu einem bestimmten Zeitpunkt wird nur ein Bruchteil der CORBA Objekte benötigt ‐ es wäre Ressourcenverschwendung, alle Objekte die ganze Zeit „am Laufen“ zu haben ‐ andererseits soll es auch nach einem längeren Zeitraum möglich sein, wieder auf das gleiche Objekt zuzugreifen ‐> Lösung: Trennung zwischen Objekt und laufendem Code Servants ‐ Ein Servand enthält den Code, der ein CORBA Interface implementiert. ‐ Er ist in einer bestimmten Programmiersprache geschrieben. ‐ Er ist Teil eines CORBA Objektes. ‐ Er kommuniziert nach aussen. ‐ Seine Methoden können in unterschiedlicher Weise aufgerufen werden, häufig durch Skeletons. Objektreferenz ‐ Objektidentität ‐ wird vom Client verwendet ‐ eine Objektreferenz verweist immer auf dasselbe Objekt ‐ mehrere Objektreferenzen können auf dasselbe Objekt verweisen ‐ Objektreferenzen: Weitergabe als Parameter, Rückgabewert oder String Aufgabe des Porable Object Adapters (POA) ‐ verbindet den Servant mit dem ORB ‐ verwaltet die Laufzeitumgebung für Objekte ‐ leitet Methodenaufrufe an den richtigen Servant weiter ‐ Abbildung einer Objektreferenz auf den zuständigen Servant ‐ transparente Aktivierung von Objekten ‐ Verbindung von Policy‐Informationen mit Objekten ‐ Ermöglichung von persistenten Objekten (über mehrere Serverprozesslebenszeiten hinweg) Lebenszyklen eines CORBA‐Objekts ‐ ein CORBA‐Objekt wird erzeugt. Es kann aktiviert (mit einem Servant assoziiert) werden, z.B. sobald ein Request vorliet. ‐ Ein Objekt kann während seiner Lebenszeit Requests durch mehrer Servants bearbeiten lassen, die nacheinander das CORBA‐Objekt verkörpern (invarnate) und es wieder verlassen (etherealize). ‐ CORBA‐Objekte können innerhalb ihrer Lebenszeit aktiv sein, bis sie schiesslich zerstört werden. 49 | Chrösch POA instanzieren und Objekt kreieren Lokale Transparenz: Der CORBA Namensdienst ‐ wichtigster CORBA Dienst ‐ wird von jeder CORBA Implementation angeboten ‐ Namensdienst bildet einen für Menschen „verständlichen“ Namen auf eine Objektreferenz ab Servant bei Namensdienst registrieren Client Objekt via Namensdienst erzeugen 50 | Chrösch CORBA Dienste Naming Service ‐ Damit auf ein Objekt (genauer: auf seine zugehörige CORBA‐Objektreferenz) über den Naming Service zugegriffen werden kann, muss es zunächst registriert, also an einen Namen gebunden werden. ‐ Dafür stellt das NamingContext Interface folgende Methode zur Verfügung: void bind(in Name n, in Object obj)…; ‐ Der erste Parameter vom Typ Name ist als Sequenz von Namenskomponenten definiert, die einen Pfad durch das Namensverzeichnis bildet: struct NameComponent { string id; string kind; }; typedef sequence <NameComponent> Name; ‐ Dies ermöglicht das Ansprechen beliebig verschachtelter Kontexte mit einem einzigen Methodenaufruf und sorgt für die einfache Handhabbarkeit von Namensverzeichnissen. ‐ OMG gibt keine Vorgabe für Namensverzeichnisse. Event Service ‐ Im Falle von nicht mit oneway gekennzeichneten Methoden blockiert der Aufruf, bis der Server mit dessen Abarbeitung fertig ist. Ausserdem muss der Client möglicherweise Exceptions, die auf der Serverseite auftreten können, abgefangen und entsprechend behandeln. ‐ Für eine Anzahl von Anwendungen ist es jedoch wünschenswert, die Kommunikation stärker zu entkoppeln. Über den Event Service ist lose gekoppelte oder Ereignis basierte Kommunikation möglich. Dabei wird zwischen Objekten unterschieden, die Ereignisse erzeugen (Suppliers) und denen, die Ereignisse verarbeiten (Consumers). ‐ Die OMG definiert zwei grundlegende Modelle für Ereignis basierte Kommunikation: ‐ Beim Push Modell sind die Suppliers die aktiven Objekte: sie „schieben“ die Ereignisdaten zu den Consumer Objekten. ‐ Umgekehrt ist es beim Pull Modell: hier fragen die Consumers explizit nach Ereignissen. Trading Object Service Die zentrale Komponente des Trading Service ist der Trader, der Angebot und Nachfrage zusammenbringt. ‐ Er wird von den so genannten Exporteuren benutzt, um ihre Dienste anbieten, und von den Importeuren, um diese Dienste zu beziehen. ‐ „gehandelt“ wird dabei nicht mit beliebigen Objekttypen, sondern mit so genannten Service Types, die sowohl den Exporteuren als auch den Importeuren bekannt sein müssen. ‐ Jedem Service Type liegt ein IDL‐Interface zu Grunde, welches von Exporteuren implementiert wird, und von Importeuren zum Zugriff auf das Dienst erbringende Objekt benutzt wird. 51 | Chrösch Persistent State Service ‐ Der Persistency State Service stellt eine Schnittstelle zur Realisierung von Objektpersistenz zur Verfügung. ‐ Die OMG spezifiziert für den Persistent Object Service einige Protokoll‐Interfaces, die den Datenaustausch zwischen PO und PDS übernehmen. ‐ Query Service| Life Cycle Service | Collection Service | Concurrency Service | Property Service | Enhanced View of Time | Relationship Service | Externalization Service | Security Service | Time Service | Licensing Service | Transaction Service CORBA Dienste sind formal durch IDL‐Schnittstellen beschrieben! Dynamischer Methodenaufruf CORBA Vision Ablauf: ‐ Frage beim Trader nach Objekten mit bestimmten Eigenschaften ‐ Objektauswahl ‐ Verwendung der Methoden des Objektes ‐ das Serverobjekt kann jünger sein als die Client Anwendung Zwei wesentliche Schritte 1. Schritt ‐ Wie sieht das Objekt aus? ‐ Information aus dem Schnittstellenverzeichnis 2. Schritt ‐ Erzeugung von Methodenaufrufen basierend auf der Information des Interface Repository ‐ dynamische Methodenaufrufe Das Ziel ‐ Der Client erhält zur Laufzeit Informationen über das Objekt. ‐ Der Client generiert zur Laufzeit einen Methodenaufruf. ‐ Die Methode hat u.U. während der Implementation des Clients noch nicht existiert. Überlegung ‐ Welche Information wird bei einem Methodenaufruf übergeben? ‐ Diese Information muss dann auch bei einem dynamischen Methodenaufruf mitgegeben werden. 52 | Chrösch Information einer Methode 53 | Chrösch Einsatz dynamischer Methodenaufrufe ‐ Dynamische Methodenaufrufe können nicht blockierend durchgeführt werden. Der Client überprüft später selber, ob der Methodenaufruf beendet ist und erhält dann die Resultate. ‐ Subs müssen nicht beim Client verteilt / installiert werden. 54 | Chrösch 16 – Refactoring: Einleitung Was ist Refactoring? ‐ Interne Struktur einer Software verändern, um die Verständlichkeit und die Wartbarkeit zu verbessern, jedoch ohne deren Verhalten zu verändern. ‐ Restrukturierung einer Software mittels Einsatz einer Reihe von Refactoring ohne deren sichtbares Verhalten zu beeinflussen. (Martin Fowler) Martin Fowler als Vorreiter in dieser Disziplin Motivationen für das Refactoring ‐ Verbesserung des Designs ‐ Code an der richtigen Stelle plazieren ‐ Erweiterungs‐ und Wartungsfreundlicher ‐ Erhöhung der Verständlichkeit ‐ Code wird selbsterklärend ‐ Erweiterungs‐ und Wartungsfreundlicher ‐ Vermeidung doppelten Codes ‐ Vorteile klar ‐ Erweiterungs‐ und Wartungsfreundlicher ‐ Vermeidung / Verminderung von Fehlern ‐ Wird die Strukturierung verstärkt und verbessert, können Fehler gefunden werden ‐ Verbesserung der Produktivität: Ein gutes Design und ein verständlicher Quelltext sind die wichtigsten Voraussetzungen um ‐ neue Funktionalität effizient einbauen zu können ‐ bestehende Funktionalität zu verändern / korrigieren ‐ Erweiterungs‐ und wartungsfreundlichere Software! Wann wird Refactored? ‐ Bei Erweiterung des Codes ‐ Codestruktur verbessern, bevor neue Funktionen hinzugefügt werden ‐ Zukünftige Erweiterungen vereinfachen ‐ Bei der Korrektur von Fehlern ‐ Auseinandersetzung mit der Struktur hilft den Fehler schneller zu finden ‐ Ein Bug ist grundsätzlich ein Hinweis, dass der Code noch nicht „sauber“ ist: Darum auch die (Unit)‐Tests verbessern! ‐ Im Rahmen einer Code‐Review ‐ eigener Code ist (meistens) verständlich, aber ist er das auch für andere? (Code Review) ‐ ‘XP‘ realisiert im Rahmen des Peer‐Programming quasi ein Continuous Code Review ‐ Kontinuierlich, während der Entwicklung ‐ Continuous Refactoring Voraussetzung für erfolgreiches Refactoring ‐ Vor dem Refactoring unbedingt sicherstellen, dass für den zu überarbeitenden Code eine stabile Testsuite zur Verfügung steht. ‐ Diese Tests müssen automatisiert sein. 55 | Chrösch ‐ Software vor und nach dem Refactoring testen ‐ es dürfen keine Differenzen auftreten ‐ Ausnahme: Durch die Verbesserung der Struktur kann u.U. natürlich der Speicherbedarf gesenkt, oder die Performance verbessert werden ‐ Einbau von Fehlern durch das Refactoring darf auf keinen Fall passieren! Beispiele von Refactorings Verfügbares Refactorings ‐ Refactorings werden anhand der konkreten „Veränderungen“ beschrieben. ‐ die zentrale Veränderung kann sehr simpel sein, jedoch grösseren Einfluss auf die restliche Software haben ‐ Beispiel: Beim Umbenennen einer Methode müss(t)en sämtliche Aufrufe ebenfalls angepasst werden! ‐ Viele Refactorings lassen sich automatisiert durchführen, womit sich die Fehlerrate drastisch reduzieren lässt. Beispiel Rename Umbenennen von ‐ Variablen ‐ Parametern ‐ Methoden ‐ Klassen ‐ Interfaces ‐ Packages Vorteile: ‐ Bessere Verständlichkeit ‐ einheitlichere und analoge Namensgebung ‐ Technisch einfach Refactoring (Search&Replace) Nachteil: ‐ Lokale Renamings (private): Praktisch keine! ‐ Globale Renamings: Potentieller Impact auf Umsysteme, mögliche Inkompatibilitäten von Schnittstellen! ‐> Schnittstellen immer von Anfang an sehr kritisch und wohlüberlegt entwerfen! Beispiel Extract Method ‐ Extrahieren eines Statementblocks in eine neue Methode ‐ Methode erhält einen aussagekräftigen Namen ‐ Code im aufrufenden Kontext wird kompakter ‐ Potentielle Coderedundanzen werden/können damit reduziert werden ‐ Referenziert der Code lokale Variablen, werden für diese in der Methoden‐Signatur automatisch formale Parameter definiert ‐ Aber: Einfachste Lösung (lange Parameterliste) ist nicht immer die Beste! Vorteile: ‐ Quellcode wird strukturiert und übersichtlicher 56 | Chrösch ‐ Aufrufender Kontext wird kürzer ‐ Chance auf Wiederverwendung der Mehtode ‐ Zentrale Fehlerbehebung, Einheitlichkeit, weniger Redundanzen Nachteile: ‐ u.U. können die Methoden lange formale Parameterlisten erhalten, was unübersichtlich ist ‐ Performance sinkt (theoretisch) Î WEITERE BEISPIELE IM SCRIPT Tools für Refactoring ‐ Toolunterstützung für Code‐Refactoring noch nicht sehr lange verfügbar (wenige Jahre), nun aber grösstenteils direkt in die IDE’s integriert. ‐ Wurde über einfache Hilfsfunktionen wie z.B. „Generate Setter/Getter“ (vergleiche „Encapsulate Fields“ in Netbeans) populär und akzeptiert. ‐ Aktuelle Entwicklungsumgebungen unterstützen mit unterschiedlichem Umfang die wichtigsten Refactorings. ‐ Massgeblich gefördert durch folgende IDE's: ‐ Eclipse, NetBeans und IntelliJ Einsatz der Tools ‐ Einsatz der Tools sollte immer wohlüberlegt erfolgen! ‐ Es hat seinen Grund, dass praktisch alle Refactoring‐Tools vor der eigentlichen Veränderung einen „Preview“ anbeiten. ‐ Vorgeschlagene Änderungen unbedingt kritisch überprüfen, einzeln durchgehen! ‐ Sonst wird aus einem Refactoring ein Destroying, was der Absicht wiederspricht Zusammenfassung ‐ Korrektes Refactoring von Software verbessert deren Qualität, Wartbarkeit, Erweiterbarkeit und Verständlichkeit. ‐ Es existiert eine Anzahl von bekannten Refactorings, welche in vielen IDE's automatisiert (oder zumindest mit viel Unterstützung) durchgeführt werden können. ‐ Wichtig: Refactoring darf nie die Funktion einer Software beeinflussen. Automatisierte Tests vor und nach dem Refactoring gewährleisten eine erhöhte Sicherheit. ‐ Jedes Refactoring – so einfach es auch schien – sollte wohlüberlegt durchgeführt werden ‐ Impact nicht nur auf eigene Software, sonder auch Umsysteme wenn API betroffen! 57 | Chrösch 17 – UML Diagramme: Modelle und UML Diagramme Elemente eines UseCases ‐ Akteur (Actor) Ein externes System (meist der Nutzer), das mit dem betrachteten System im Rahmen des Anwendungsfalls interagiert. ‐ Szenarion (Scenario) Ein konkreter Ablauf des Anwendungsfalls (instance) ‐ Ein Standardszenario, mehrere Varianten. ‐ Beziehungen (Relations) Zwischen Akteur und UseCase ‐ … oder zwischen verschiedenen Anwendungsfällen Anwendungsfallmodell erarbeiten ‐ Ziele ‐ Systemgrenzen festlegen (was gehört zum System, was ist Teil der Umgebung) ‐ Übersicht über die Akteure und ihre Anwendungsfälle ‐ Begriffe / Terminologie der Anwendung erfassen (Glossar) ‐ Quellen ‐ Stakeholders (Kunden, Nutzer, Partner) ‐ Business/Domain Modell, Kundenanforderungen ‐ Vorgehen ‐ Akteure suchen ‐ Anwendungsfälle suchen ‐ Jeden Anwendungsfall beschreiben ‐ Das Anwendungsfallmodell als ganzes beschreiben (incl. Glossar) Akteure erfassen ‐ Beispiele für Akteure (Rollen): ‐ Bearbeiter von Geschäftsfällen ‐ Personen / Systeme die Anfragen auslösen oder Entscheide fällen ‐ externe Systeme ‐ System‐Wartung und –Support ‐ Kriterien ‐ Es muss mind. Einen Nutzer geben, der Akteur‐Rolle spielt oder den Akteur auslöst 58 | Chrösch ‐ Die Rollen sollen sich möglichst nicht überschneiden ‐ Beschreibung ‐ Name des Akteurs (Rollenbezeichnung) ‐ Zweck des UseCases; Erwartungen des Akteurs ans System; zu erbringende Leistung Anwendungsfälle ermitteln ‐ Ein UseCase liefert ein nützliches Ergebnis für den Akteur, z.B. Anwendungsfälle für ‐ Rollen im Business‐ bzw. Domain‐Modell ‐ Geschäftsobjekte (erzeugen, verändern, löschen…) ‐ Ereignisse (Umwelt ‐> System oder System ‐> Umwelt) ‐ das Hoch‐ und Runterfahren des Systems bzw. für die Wartung ‐ Namensvergebung: Verb (+ Substantiv) Interaktion (+ Ergebnis) ‐ Abgrenzung ‐ Zeitliche Entkoppelung ‐ Andere Datenbenützung ‐ Iterativ herantasten (‐> Architekturentwurf) UseCase Diagramm UseCase Beschreibung Jeder UseCase wird beschrieben durch: ‐ einen eindeutigen Namen, möglichst Substantiv + Verb ‐ einen kurzen Erläuterungstext von ca. 2‐20 Zeilen ‐ eine Liste mit den beteiligten Akteuren ‐ Benennung wichtiger Auslöser / Vorbedingungen ‐ Benennung wichtiger Ergebnisse / Nachbedingungen ‐ Benennung wichtiger Dokumente und Ansprechpartner ‐ eine Beschreibung der einzelnen Ablaufschritte mit: ‐ Namen, möglichst Substantiv + Verb ‐ Stichwortartige Erläuterung Beziehungen zwischen UseCases <<include>> Teile die in mehreren UseCases vorkommen, können in einen eigenen UseCase ausgelagert und mit <<include>> wieder eingebunden werden. <<extend>> erlaubt einen UseCase an einem festgelegten ExtensionPoint mit einem anderen UseCase zu erweitern wenn eine estimmte Bedingung erfüllt ist. 59 | Chrösch Generalisierung / Spezialisierung Mittels Vererbung lässt sich das UseCase Modell hierarchisch strukturieren, dabei werden Abläufe und Akteur‐Beziehungen vererbt. Für Beziehungen zwischen UseCases gilt: weniger ist mehr! <<include>> Vererbung und <<extend>> Aktivitätsdiagramm ‐ Zweck ‐ Beschreibung von Geschäftsprozessen ‐ Beschreibung von UseCase Szenarien ‐ Modellierung paralleler Abläufe ‐ Aktivitätsdiagramme wurden aus Fluss‐ / Event‐ , SDL‐ und Zustandsdiagrammen in UML übernommen und weiter entwickelt. ‐ Aktivitätsdiagramme werden auch von Personen ohne spezielle Informatikkenntnisse gut verstanden und sind deshalb äusserst hilfreich in der Analyse. Grundelemente: 60 | Chrösch Verzweigung und Aufteilung Partielle Abläufe ‐> Partitionen Verfeinernde Zerlegung Eine Aktivität kann in einem anderen Aktivitätsdiagram weiter verfeinert werten. Natürlich muss die Verfeinerung gleich viele Start‐ und Endpunkte haben, wie die abstrakte Aktivität Ein‐ und Ausgänge besitzt. Aktivitäten mit Unteraktivitätsmodellen können durch ein kleines ActivityDiagram Icon gekennzeichnet werden. Zeitereignisse, Signale & Unterbrechung ‐ Signal senden erfolgt im Fluss, dieser wird davon nicht unterbrochen ‐ Signal empfangen kann ebenfalls im Fluss erfolgen (Synchronisation) oder aber isoliert in einem unterbrechbaren Bereich: 61 | Chrösch ‐ Symbole: Objektnoten und Objektfluss „Rechnung schicken“ verändert (erstellt) die „Rechnung“, diese wird zu „Zahlung ausführen“ übertragen. DataStore Zentraler Speicherknoten für nicht‐transistente Daten. Bewahrt alle einkommenden Daten auf. Aktivitätsbeschreibung Klassendiagramm: Beziehungen ‐ Assoziation (benutzt‐Beziehung) 62 | Chrösch ‐ Aggregation & Komposition (hat‐Beziehung) ‐ Generalisierung (ist‐Beziehung) Beispiel Geldautomat Das Klassendiagramm beschreibt die statische Struktur der Objekte in einem System sowie ihre Beziehungen untereinander. Elemente im Klassendiagramm Generalisierung: ist‐Beziehung ‐ Klassen können auch durch Spezialisierung von allgemeineren Obj‐Klassen hervorgehen ‐ Generalisierung wird meist durch Vererbung implementiert ‐ Notation Beispiel ‐ Implementation von Interfaces wird durch gestrichelte Linien dargestellt Assoziationen Die Assoziation stellt eine allgemeine Beziehung zwischen zwei Klassen dar, über die Realisierung wird dabei nichts ausgesagt. Die Aggregation ist eine besondere Assoziation, die durch eine Raute an der Linie dargestellt wird. Sie gibt an, dass z.B. die Klasse Kartenleser in der Klasse Geldautomat ‘enthalten‘ ist (Ist‐Teil‐von). Die Komposition ist eine stärkere Form der Aggregation, die durch eine ausgefüllte Raute dargestellt wird. Bei der Beziehung Komposition handelt es sich um ein physisches enthalten sein. 63 | Chrösch Assoziation – Aggregation Komposition Assoziation: benutzt‐Beziehung ‐ Modelliert eine allgemeine Beziehung zwischen Klassen ‐ Assoziation = Menge aller Verbindungen zwischen den Objekten der beteiligten Klassen ‐ Meist als Zeiger implementiert (Java Objektreferenz) ‐ Assoziations‐Name / ‐Rolle / ‐Navigierbarkeit / ‐Kardinalität optional (Nicht‐) Navigierbarkeit Aggregationen: hat‐Beziehung ‐ Unterschied zur Benutzt‐Beziehung (Assoziation) oft unklar ‐ Hat‐Beziehung, wenn man „besteht aus“ sagen kann ‐ Dokument hat mehrere Absätze: besteht aus mehreren Absätzen ‐ Ein Land hat eine Hauptstadt: besteht aber nicht aus ihr ‐ Echte „ist enthalten“ Beziehung, im Gegensatz zur Assoziation, die eine „steht in Verbindung mit“ Beziehung ist. ‐ Notation Beispiel 64 | Chrösch Komposition: hat‐exklusiv‐Beziehung ‐ Eigenschaften ‐ ist ein Spezialfall der hat‐Beziehung ‐ Unterscheidung zur hat‐Beziehung nicht immer einfach ‐ drückt stärkere Bindung als hat‐Beziehung aus ‐ Unterscheidungsmerkmal: Teile haben die gleiche Lebensdauer ‐ Notation ‐ Beispiel Kardinalität von Assoziationen (keine Aussage zur Kardinalität) Jedes A ist mit 3 B verbunden Jedes B ist mit 2 A verbinden Jedes A ist mit 2..4 B verbunden Jedes A ist mit 0..1 B verbunden DataFlow Jedes A ist mit 0..∞ B verbunden Attribute und Methoden Attribute ‐ Bestimmen die Struktur der Klasse ‐ Die aktuellen Werte der Attribute definieren den Zustand eines Objektes. Methoden ‐ Bestimmen das Verhalten der Objekte einer Klasse ‐ Die Funktionalität die Objekten einer Klasse zur Verfügung steht ‐ From the conceptual level, a Person’s name attribute, indicates that a Person has a name. So there is no difference between attributes and associations at the conceptual level. ‐ At the specification level, the attributes indicate, that the Person object can give you the 65 | Chrösch name and allows you to set the name. ‐ On the implementation level, the attribute specifies that the Person has a field (or data member, or instance variable) for its name. Sichtbarkeit, visibility ‐ Die Visibility kann vor dem Namen eines Attributes bzw. einer Methode mit folgenden Symbolen angegeben werden: ‐ Vollständige UML Syntax für Methoden: visibility name(parameterList): return‐type‐expression {propertyString} Interfaces ‐ interface‐Klassen haben keine Attributes und keine implementierten Methoden ‐ UML hat einen vordefinierten Stereotyp für interfaces. Abstrakte Klassen ‐ Abstrakte Klassen können sowohl Attribute als auch Methoden‐ Implementationen haben. ‐ Darstellung mittels {abstract} Constraint ‐ oder mit kursiv geschriebenen Klassennamen Aktive Klasse ‐ Zeigt an, dass ein Objekt dieser Klasse aktiv ist. ‐ Aktives Objekt hat eigenen „thread of control“. Elemente eines Sequenzdiagramms 66 | Chrösch Objekte erzeugen, Rückgabewerte, Synchron/Asynchron UML 2: Interaktion und Fragment Package Diagram 67 | Chrösch Darstellung der Modul‐Abhängigkeiten 68 | Chrösch 18 – Testing II: Testing Übersicht Testing in the V‐Model The V‐Model and it`s extension the W‐Model are especially suitable to explain the dependencies: specify with each activity the corresponding test review specs, design documents and test specs run the tests against the appropriate design level distinguish verification and validation Which one is Right? ‐ wrong question! ‐> only together these models show the whole picture: ‐ you have to have different levels of testing much like we learned from the V‐Model ‐ you have to provide tests for iteration results much like we learned from the USDP ‐ you have to have regression testing much like we learned from USDP and XP ‐ it`s a good advice to go for incremental acceptance another important concept from XP You need them all ‐ depending on which statistic you trust, each review or test step ‐ for example say we build an OS with 40 Mio. LOC 69 | Chrösch Maximize the Yield ‐ none of the testing methods can bring up all the bugs ‐ only the coordinated use of techniques will maximize the yield ‐ testing inevitably remains incomplete, the question therefore is: ‐ which subset of the test cases offers the highest probability to find as many errors as possible at the lowest costs? Test Design ‐ testing by poking around is a waste of time ‐ only designed and documented tests can be repeated ‐ the complexity of software requires models to support test design ‐ That is where HTAgil comes into play HTAgil Testphilosophie adquat: 100% Abdeckung nicht erreichbar, darum ‐ welche Konfigurationen (HW / Daten / SW) und Abläufe bergen die grössten Risiken ‐ was ist Teil der Abnahme ‐ was sind anwendbare Vorschriften ‐> <<adäquates Soll>> opportunistisch: Testen ist aufwändig, darum ‐ welche Tests lassen sich wann ohne grossen Aufwand (HW / Daten …) durchführen ‐ Delta zum <<adäquten Soll>> ermitteln und nach Aufwand / Ertrag abdecken HTAgil Testpakete HTAgil Test‐Ebenen 70 | Chrösch HTAgil Regressionstest HTAgil Test‐Iterationen HTAgil inkrementelle Abnahme HTAgil Testdokumentation Software Test Dokument ‐ Einführung: Kontext, Philosophie ‐ Test Plan: Einsatzplanung für Leute, Software und Ausrüstung ‐ Test Design: Was wird getestet, Test Reihenfolge, Testumgebung ‐ Testfälle: ‐ Testfall‐Beschreibung ‐ Test Prozeduren / Vorgehen Testprotokoll ‐ ID / Tester / Version / Datum ‐ Testbericht / Resultate / Log 71 | Chrösch ‐ Aufzeichnungen zum Test Softwarefehlerverfolgung ‐ z.B. Einsatz von Bugzilla ‐ Transparenz im Projekt ‐ Status der Bugfixes ‐ Fehlerstatistik ‐ <<Laborbuch>> ‐ bleibt beim SUT (System under Test) ‐ systematische Fehlerverfolgung der Software bei Kunden HTAgil Zusammenfassung Test Test‐Philosopie ‐ adäquat ‐ opportunistisch Test‐Aspekte ‐Test‐Ebenen ‐ Reviews ‐ Unit Tests ‐ Integrations‐ und Systemtests ‐ (Teil‐) Abnahmen ‐ Regressionstests ‐ Builds durchlaufen die relevanten Testsuiten ‐ Test‐Iterationen ‐ iterative Reviews ‐> Konsistenz sicherstellen ‐ iterative Tests ‐ inkrementelle Abnahmen ‐ Kunden‐Releases abnehmen lassen Test‐Dokumentation ‐ Test‐Planung und Protokoll ‐ Softwarefehlerverfolgung Integration Testing Integrationstest prüfen die Schnittstellen und das Zusammenspiel der Systemkomponenten. ‐ Iterative Entwicklung ermöglicht schrittweise Integration. ‐ Dabei wird immer wieder ein in sich stabiles (Teil‐)System angestrebt. ‐ Alle zu integrierenden Units / Komponenten sollten bereits erfolgreich getestet sein (allerdings kann eine Komponente oft erst im Verbund mit andern vollständig getestet werden). ‐ Reentrace und Interrupts: können nur statisch geprüft werden: Code, der im statischen Umfeld erfolgreich getestet wurde, kann in dynamischer Umgebung immer noch Fehler auslösen! Was testen ‐ Interfaces ‐ Objekt Kompatibilität (Typen und Wertebereiche) ‐ Aufruf‐Sequenzen 72 | Chrösch ‐ Wer validiert Inputs – der Aufrufende oder der Aufgerufene ‐ Datneabhänigkeiten für jede Komponente ermitteln, welche Datenabhängigkeiten bestehen und diese testen. ‐ CallGraph Abdeckung Bei Komponenten, die von versch. Aufrufen genutzt werden auch alle Aufrufvarianten testen. Test Design Testing by poking around is a waste of time. ‐ Häufig wird versucht Testfälle durchzuspielen ohne seriös die Anforderungen an das Programm und die entsprechenden Randbedingungen untersucht zu haben. ‐ Nur systematisch geplante und dokumentierte Tests können zuverlässig wiederholt werden (Regression). ‐ Die Komplexität der Software erfordert Modelle zur Unterstützung des Testentwurfs. Integrationsstrategie ‐ Bottom‐Up the Small kleinere Testsysteme lassen sich bottom‐up integrieren ‐ Top‐Down the Controls Bei aufwändigen Kontrollstrukturen mit Hilfe von Stubs top‐down vorgehen und dann die richtigen Komponenten integrieren. ‐ Big‐Bang the Backbone Was für den weiteren Testablauf benötigt wird in einem Aufwisch zusammenführen. ‐ Continuous Integration Bei iterativ‐inkrementeller Entwicklung neu dazu gekommenes laufen integrieren und testen. 73 | Chrösch 19 – Deployment: Übersicht: Deployment ‐ Verteilung: Versand von Datenträgern mit Programm und Dokumentation, zur Verfügung stellen von entsprechenden Downloads, automatisiertes Installation (z.B. Java Webstart) ‐ Installation: Kopieren der nötigen Dateien an die vorgesehenen Orte und Registrieren der Anwendung, allenfalls überprüfen, ob das Zielsystem für die Anwendung geeignet ist (Hardwareausstattung, Betriebssystemversion etc.) ‐ Konfiguration: Einstellungen der/des Programme(s) auf Benutzer, Netzwerkumgebung, Hardware etc. ‐ Organisation: Information, Schulung, Support, Planung, Produktion Wann findet Deployment statt? ‐ Deployment findet natürlich am Ende des Projektes statt ‐ Aber: Aufgrund iterativer Entwicklungsmodelle (u.a. HTAgil) gibt es auch ein iteratives Deployment! ‐ einzelne Iterationsergebnisse werden fortlaufend deployed, z.B Alpha, Beta etc. ‐ Verbindung bzw. Analogie zum Testen! ‐ Abhängig von der Grösse des Projektes passiert das Deployment im Verlaufe des Projektes auch auf unterschiedliche Umgebungen! ‐ Entwicklung, Test, Integration, Vor‐Produktion, Produktion ‐ so genanntes „Staging“ Deployment‐Umfang ‐ Deployment umfasst einerseits technische Aspekte wie ‐ Deployment Diagramme (Zuordnung Komponenten / Hardware) ‐ Installations‐ und Deinstallationsprogramme / ‐skripte ‐ Konfiguration (Default~, Beispiel~ etc.) ‐ Aber auch organisatorische Aspekte: ‐ Konfigurationsmanagement – Aus welchen Komponenten besteht welcher Release? ‐ Installations‐ und Bedienungsanleitungen ‐ Erwartungsmanagement – Welche Funktionalität ist vorhanden? ‐ Support bereitstellen UML 1.x Deployment Diagramm 74 | Chrösch UML 2 Deployment Diagramm ‐ Node: Stellt einen Computer (Host) oder eine sonstige Hardware dar (identisch zu UML 1.x) ‐ Artifact: Stellt ein ausführbares Binary, ein Skript etc. dar, welches durch die Installation explizit einem Node zugeordnet wird. ‐ wird in einer Deployment‐Spezifikation detaillierter beschrieben UML 2 Deployment Spezifikation zusätzliche Angaben über die Konstruktion einer Einsatzkonfiguration <<manifest>> verbindet ein Artefakt mit einer Komponente ‐ Beispiel: Die Komponente Order wird durch order.jar realisiert Installation und Deinstallation ‐ Installation (oder Update) der Software sollte automatisiert (‐> Reproduzierbar) sein ‐ Deinstallation ist ebenfalls wichtig ‐ Beispiele unterschiedlicher Kunden: ‐ Grafische, interaktive GUI‐Installation für Endanwender auf dem Desktop ‐ Möglichst Script‐basierte, durch Parameterisierung voll automatisierte Installation ‐ oder Automatische Verteilung (Software‐Management) ‐ z.B. Java Webstart Default‐ und/oder Beispiel‐Konfigurationen Zielkonflikt: Installierte Anwendung soll: ‐ möglichst sofort out‐of‐the‐box lauffähig sein ‐ sich an verschiedne vorhandene Umsysteme anpassen können Typische Beispiele: ‐ Datenbankanwendung: Einsatz einer bestehenden DBMS‐Umgebung ‐ Logging / Audit: Einsatz unterschieldicher Logging‐ und Überwachungs‐Mechanismen ‐ Security: Support verschiedener Authentifizierungs‐ und Autorisierungs‐Techniken (z.B. LDAP, Kerberos etc.) 75 | Chrösch Deployment – Installationsmedium/‐quelle ‐ Klassisch: CD, DVD ‐ Produktion braucht Zeit ‐ Download von Server (http, ftp, etc.) ‐ Bandbreite? ‐ Zugang sichern, Authentifizierung ‐ USB‐Stick ‐ eher eine ad‐hoc‐Lösung, für einzelne Nodes Deployment – Konfigurationsmanagement ‐ Verschiedene Kunden haben unterschiedliche Versionen einer Software. Wer hat was? ‐ Verschiedene Kunden haben unterschiedliche Produkte und Versionen im Umsystem (z.B. Datenbank) und der Hardware (z.B. Einfluss auf Performance) ‐ Wer hat welche Konfiguration? Mit welchen Komponenten? ‐ Welche Kombinationen sind überhaupt lauffähig? ‐ Ist ein Update von jeder existierenden Konfiguration möglich? ‐ Müssen bestimmte Abfolgen eingehalten werden? ‐ Wurden die unterschiedlichen Szenarien auch getestet? Deployment – Manuals Installationsanleitung ‐ Installation möglichst automatisieren ‐ Varianten aufgrund unterschiedlicher Konfiguration berücksichtigen ‐ Haben sich HW‐ oder SW‐Voraussetzungen geändert? ‐ Müssen bestimmte Abfolgen eingehalten werden? Bedienungsanleitung ‐> Release Notes ‐ Der neue Release hat einen neuen Funktionsumfang ‐ Der neue Release hat andere / weitere Vorbedingungen ‐ Der neue Release hat neue / geänderte Datenformate oder Protokolle Deployment –Erwartungsmanagement ‐ Oft erwarten Kunden bzw. Anwender mehr als was die Entwicklung versprochen hatte Entsprechend negativ wird die Rückmeldung sein, was nicht zu einem guten und produktiven Klima in der Entwicklung und gegenüber dem Kunden beiträgt. ‐ Erwartungsmanagement heisst vor allem: ‐ sich bewusst werden, was wann wie kommuniziert wird ‐ konsistent informieren ‐ keine Widersprüche zwischen Worten und Taten, speziell was den Umfang betrifft Deployment – Support ‐ Auch wenn alles getestet wurde, … ‐ Auch wenn für alle Abläufe Instruktionen vorliegen … ‐ … speziell Software‐Updates gehen trotzdem häufig schief ‐ Bedienungs‐ oder Anwendungsfehler ‐ Unerwartete und/oder veränderte Konfigurationen ‐ z.B. durch spezielle Datenbestände ‐ Wenn der vorgegangene Release produktiv war, sind die Erwartungen hoch 76 | Chrösch Releases und Versionierung ‐ Deployment findet mit einem wohldefinierten Release statt ‐ Eindeutige Bezeichnung und Version ‐ Technische Version ist die eindeutige Grundlage ‐ ‚Tagging‘ im Versionskontrollsystem ‐ ‚Marketing‐Version‘ kann Ergänzung sein ‐ Bewährt: Dreistellige Version: x.y.z (z.B. 1.2.15) mit Semantik ‐ Anhand der Version soll möglichst einfach und klar ersichtlich sein, was prinzipiell ‚passiert‘ ist: ‐ Änderungen, Erweiterungen oder Korrekturen ‐ Version hat speziell bei technischen Releases (z.B. Libraries) eine wichtige Aussage Einfache 3‐stellige Versionierung ‐ Version X.Y.Z ‐ Major‐Release (X.x.x): Veränderung in der API, in der fachlichen Funktion oder in der Konfiguration, welche zu früheren Versionen nicht mehr kompatibel ist und somit Anpassungen notwendig macht. ‐ Minor‐Release (x.X.x): Erweiterung in der API, der fachlichen Funktion oder Konfiguration, welche aber vollständig Rückwärtskompatibel ist und (zumindest ohne Nutzung derselben) keine Anpassungen notwendig macht. ‐ Bugfix‐Release (x.x.X): Reine Korrektur oder Änderung in der Implementation, vollständig kompatibel, keinerlei neue Funktionen, keine veränderte Funktionen, direkter Einsatz. Release‐Notes ‐ Sauberes Nachführen allen Änderungen, Erweiterungen und Korrekturen. ‐ Nachvollziehbare Entwicklungsgeschichte ‐ Meist manuell nachgeführt, da qualitative Aussage ‐ Evt. unterstütz durch Issue‐Tracking‐Systeme ‐ Bugzilla, JIRA, Trac etc. ‐ Direkter Bezug auch Change‐Request oder Bug ‐ Für Entwickler die zentrale Informationsquelle um Möglichkeit bzw. Notwendigkeit einer Migration auf eine neue Version und das damit verbundene Risiko einschätzen zu können. Beispiel: Open Source Projekte ‐ Deployment erfolgt häufig über zwei verschiedene Distributionen: ‐ Binär‐Distribution – enthält typisch binäre Runtime plus Doku, direkt einsetzbar ‐ Source‐Distribution – enthält nur Quellcode und alle nötigen Buildartefakte ‐ Merke: Aus der Source‐Distribution sollte die Binär‐Distribution jederzeit erstellt werden können. ‐ Entwicklungswerkzeuge (JDK etc.) vorausgesetzt ‐ Distributionen werden sauber versioniert ‐ typisch: dreistelliges Versionskonzept Zusammenfassung ‐ Deployment: Geordnete ‚Lieferung‘ des Sw‐Endproduktes an den Kunden. ‐ Nicht nur technische, sondern auch organisatorische Aspekte. 77 | Chrösch ‐ Installationsplattformen können sehr Unterschiedlich sein (zwischen Entwickler und Endanwender/Produktion, und auch Umgebungen) ‐> Konfigurationsmanagement ‐ Deployment wird von Entwicklern sehr häufig massiv unterschätzt. ‐ Sauberes Releasing und Versionierung ist als Grundlage für das Deployment sehr wichtig. 78 | Chrösch 20 – SWK Dokumentation: Übersicht Doku & Repetition Nutzen der Dokumentation ‐ Viele Dokumente wie z.B. Softwarearchitektur sind bereits (Zwischen‐)Produkte des Entwicklungsprozesses. ‐ Dokumentationsarbeit hilft beim Problemverständnis (z.B. Kundenanforderungen, Softwareanforderungen) und bei der Konsensbildung (z.B. Architekturmodelle, Projektpläne). ‐ Dokumentation leistet einen Beitrag zur Wissenssicherung (80% der Softwareentwicklung ist Pflege bestehender Systeme). Dokumentation: Was? – Für wen? Dokumentation nach IEEE Agile Dokumentation? Agile Manifesto: „working software over comprehensive documentation“ ‐ Wie schafft man die Gratwanderung zwischen dem Zuviel und dem Zuwenig an Doku? ‐ Wie erreicht man die Balance zwischen Aufwand und Nutzen? 79 | Chrösch ‐ Welche Doku ist nützlich? Agile Dokumentation ‐ legt aus dem Projektkontext heraus bewusst fest, was dokumentiert werden soll ‐ ist inhaltlich aktuell und korrekt, gleichzeitig aber kompakt und gut strukturiert ‐ ist nicht lästige Pflicht, sonder effektiver Beitrag zur Unterstützung der anderen Projektaufgaben HTAgile Dokument Dokumentation Kundenanforderung ‐ Kundenanforderungs‐Dokument Dokumentation Systemspezifikation ‐ Systemspezifikations‐Dokument Software Dokumente ‐ Code und innere Dokumentation (z.B. Javadoc) / Kommentare ‐ Software Test Dokument ‐ Bedienungsanleitung Unterstützende Dokumente ‐ Projekt Management Plan HTAgil Dokument: Kundenanforderung HTAgil Dokument: Systemspezifikation 80 | Chrösch Umgang mit Änderungen Beim iterativ‐inkrementellen Vorgehen haben verschiedene Releases unterschiedliche Spezifikationen und Architekturen, die möglicherweise untereinander nicht konsistent sind. ‐ Konsistente Versionen in entsprechenden Unterkapiteln oder konsistente Versionen der Systemspezifikation pro Release ablegen HTAgil Projektmanagement Plan Versionskontrolle ‐ Dokumente entstehen und verändern sich im Laufe jedes Entwicklungsprozesses, nicht nur bei iterativ‐inkrementellem Vorgehen. ‐ Es ist daher wichtig, den Stand eines Dokumentes zu kennen. ‐ Vielfach ist es eine Prozessvorgabe, dass die Produktentstehung aus den Dokumenten nachvollziehbar sein muss. Dokumente müssen einer Versionsverwaltung unterworfen werden. Systemspezifikation aus Sicht SWK At the root of all the problems we have with software lies the failure of software developers to document design decisions in a way that allows those decisions to be reviewed, to guide the implementers, to guide the testers and to guide those who will maintain it in the future. Systemspezifikation – Vorgehen ‐ Anforderungen verfeinern, spezifizieren ‐ Architekturübersicht erstellen, Realisierbarkeit prüfen ‐ Datenmodell erstellen, GUI‐Skizzen … ‐ Anforderungen an die Umgebung (Enviroment) festhalten 81 | Chrösch Vorgehen beim Architekturentwurf (KREISLAUF) 1. Aufgabe analysieren ‐ Anforderungen verstehen ‐ Vorhandene bzw. beschaffbare Technologien und Mittel analysieren 2. Architektur modellieren ‐ Grundlegende Systemarchitektur festlegen (Architekturmuster) ‐ Festlegung des Architekturstils ‐ Modularisieren ‐ Nebenläufige Prozesse gliedern ‐ Wiederverwendungs‐ und Beschaffungsentscheide treffen ‐ Ressourcen zuordnen ‐ Aspektbezogene Teilkonzepte für Querschnittsaufgaben erstellen ‐ Lösungskonzept erstellen 3. Lösungskonzept prüfen ‐ Anforderungen erfüllt? ‐ Softwaretechnisch gut? ‐ Wirtschaftlich? HTAgil Systemspezifikation 1. Systemübersicht/Kontext 2. Modelle 2.1 Analyse‐Modell Bei Bedarf ein OOA‐Modell zur Analyse der Anforderungen erstellen 82 | Chrösch 2.2 Architektur‐Modell ‐ Conceptial View (Lofical View, Kontext‐Sicht) 83 | Chrösch ‐ Structure View (Module View, Implementation View, Bausteinsicht) ‐ Execution View (Component&Connection View, Process View, Lufzeitsicht) 84 | Chrösch ‐ Allocation View (Deployment View, Verteilung) 85 | Chrösch 2.3 Daten‐Modell Bei Bedarf ein Konzeptionelles ER‐Diagramm erstellen (ableiten aus OOA) 3. Spezifikation Schnittstellen ‐ Describe the methods of interaction and the rules governing those interactions. ‐ The methods of interaction include the mechanisms for invoking or interrupting the entity, for communicating through parameters, common data areas or messages, and for direct access to internal data. ‐ The rules governing the interaction include the communications protocol, data format, acceptable values, and the meaning of each value. ‐ Provide a description of the input ranges, the meaning of inputs and outputs, the type and format of each input or output, and output error codes. ‐ Fore User Interface include inputs, screen formats, and a complete description of the interactive language. 86 | Chrösch 87 | Chrösch