Softwaretechnik 6. Software- & Systementwurf (PDF)

Vorlesung Softwaretechnik 6. Software- und Systementwurf Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Entwurfsprinzipien Warum? Was?...

Vorlesung Softwaretechnik 6. Software- und Systementwurf Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Farbe! Warum, was, wie und wozu? Entwurfsprinzipien Warum? Was? Wie? Wozu? Problem in kleine Vorbereitung für die Hochgradig Grobentwurf: Architektur, Einheiten zerlegen, Implementierung großer, Praxisrelevant Komponenten komplexer Systeme, die Subsysteme und Schnittstellen realisieren, in Teams entwickelt zusammensetzen werden Von der Analyse zum Entwurf kommen Feinentwurf: Komponenten, Softwarearchitekturen, Kommunikation mit Optimale Technologie Datenstrukturen, Taktiken Stakeholdern gibt es nicht Algorithmen 2 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, Analyse Entwurf Wartung 6. Software- & Systementwurf tierung Integration 6.1. Entwurfsprinzipien Grobentwurf Feinentwurf Prof. Bernhard Rumpe Literatur: Software Engineering Sommerville 10 RWTH Aachen Balzert Band I LE 23 Balzert Band II LE 17 http://www.se-rwth.de/ Software-Entwurf Ausgangspunkt: - Anforderungsspezifikation (Pflichtenheft) und - Funktionale Spezifikation (Produktdefinition) Ziel: - Vom „WAS“ zum „WIE“: Vorgabe für Implementierung Subsystem § in sich geschlossen § eigenständig funktionsfähig mit definierten Schnittstellen § besteht aus Komponenten Komponente § Baustein für ein Softwaresystem (z.B. Modul, Klasse, Paket) § benutzt andere Komponenten § wird von anderen Komponenten benutzt § kann auch aus Unterkomponenten bestehen 4 Software Engineering | RWTH Aachen Gliederung des Entwurfsprozesses Architektur-Entwurf Gesamtstruktur Subsystem- & Schnittstellen-Spezifikation des Systems (Grobentwurf) Komponenten-Entwurf Detailstruktur Datenstruktur-Entwurf des Systems Algorithmen-Entwurf (Feinentwurf) Grobentwurf: - weitgehend unabhängig von Implementierungssprache Feinentwurf - angepasst an die Implementierungssprache und Plattform 5 Software Engineering | RWTH Aachen Arbeitsteilung beim Entwurf Architekturentwurf Entwurf Entwurf Schnittstelle Schnittstelle 1«2 2«... Entwurf Entwurf Entwurf Subsystem 1 Subsystem 2 Subsystem... Entwurf der Komponenten 6 Software Engineering | RWTH Aachen Kriterien für „guten“ Entwurf Korrektheit - Erfüllung der funktionalen Anforderungen - Sicherstellung der nichtfunktionalen Anforderungen Verständlichkeit & Präzision - Gute Dokumentation Anpassbarkeit Hohe Kohäsion innerhalb der Komponenten Schwache Kopplung zwischen den Komponenten Details dazu gleich Wiederverwendung Diese Kriterien gelten auf allen Ebenen des Entwurfs (Architektur, Subsysteme, Komponenten) 7 Software Engineering | RWTH Aachen Kohäsion Kohäsion ist ein Maß für die Zusammengehörigkeit der Bestandteile einer Komponente. Hohe Kohäsion einer Komponente erleichtert Verständnis, Wartung und Anpassung. Kohäsion wird erreicht durch: - Prinzipien der Objektorientierung (Daten & Methoden-Kapselung) - Einhaltung von Regeln zur Paketbildung - Verwendung geeigneter Muster zu Kopplung und Entkopplung „Kohärente“ Klasse: Es gibt keine Partitionierung in unabhängige Untergruppen von zusammengehörigen Operationen und Attributen 8 Software Engineering | RWTH Aachen Grade der Kohäsion (wenig bis hoch) Zufällige Aufruf/ Sequentielle - Beliebige Bestandteile in einer Komponente - Ausgabe eines Bestandteils der Komponente = Eingabe zusammengefasst z.B. utility Klassen eines anderen Bestandteils Logische - Zusammenfassung von Bestandteilen, die ähnliche Daten/ Kommunikative/ Informationale Funktionen ausführen z.B. Eingabe, Fehlerbehandlung - Bestandteile einer Komponente operieren auf Zeit/Zeitliche gemeinsamen Daten (gleiche Eingabe- oder - Die Bestandteile der Komponente werden zur gleichen Ausgabedaten) Zeit aktiviert, Gruppierung nach der gemeinsamen Ausführungszeit z.B. bei Systemstart, in einem Funktionale Konstruktor, Exception Handling nach dem Öffnen einer - Jeder Bestandteil der Komponente ist für die Ausführung Datei der (einzigen) Gesamtfunktion der Komponente Ablauf/Prozedurale notwendig - Die Bestandteile der Komponente werden als geschlossene Ablauffolge ausgeführt, d.h. Gruppierung nach der Ausführungsreihenfolge z.B. Rechteprüfung vor der Datenbankanfrage 9 Software Engineering | RWTH Aachen Kopplung Kopplung ist ein Maß für die Abhängigkeiten zwischen Komponenten. Geringe Kopplung erleichtert die Wartbarkeit und macht Systeme stabiler. Arten der Kopplung: - Datenkopplung (gemeinsame Daten) - Schnittstellenkopplung (gegenseitiger Aufruf) - Strukturkopplung (gemeinsame Strukturelemente (z.B. Attribute)) Reduktion der Kopplung: - Kopplung kann nie auf Null reduziert werden! - Schnittstellenkopplung ist akzeptabel, da Flexibilität in der OO gegeben - Datenkopplung soweit möglich vermeiden! § z.B. static oder public Attribute, Vererbung - Strukturkopplung vermeiden! § z.B. keine Vererbung über Paketgrenzen hinweg Entkopplungsbeispiel: get/set-Methoden statt Attribut-Zugriff 10 Software Engineering | RWTH Aachen Wiederverwendung Wiederverwendung (reuse) ist ein Maß für die Ausnutzung von Gemeinsamkeiten zwischen Komponenten Reduktion der Redundanz Erhöhung der Stabilität und Ergonomie Hilfsmittel für Wiederverwendung: - im objektorientierten Entwurf: Vererbung, Parametrisierung - im modularen und objektorientierten Entwurf: Module/Objekte mit allgemein nutzbaren Schnittstellen (Interfaces) Aber: Wiederverwendung kann die Kopplung erhöhen: - Schnittstellenkopplung und Strukturkopplung 11 Software Engineering | RWTH Aachen Framework Framework - Eine Software, die durch Callback-Methoden erweiterbar ist - Dazu werden Subklassen gebildet und dem Framework gegeben - Aufrufe finden in entgegengesetzter Richtung statt: § das genutzte Framework ruft die eigentliche Applikation auf Applikation Applikation calls callbacks Bibliothek Framework 12 Software Engineering | RWTH Aachen Referenzmodelle und -architekturen Referenzmodell (für die Analyse) - Logische Aufteilung der Systeme einer Domäne in § Subsysteme § Verbindungen § Kommunikationskanäle zwischen diesen Subsystemen Referenzarchitektur (für die Architektur/Entwurfsphase) - Abbildung eines Referenzmodells auf Softwarekomponenten - Datenfluss, Kommunikation - Technische Aspekte werden hinzugefügt - Gruppierung der logischen Elemente auf Softwarekomponenten ist *-zu-* § Meistens realisieren mehrere Softwarekomponenten ein logisches Subsystem § Logische Elemente können mehrfach repliziert sein 13 Software Engineering | RWTH Aachen  Beispiel: Referenzmodell für Workflowmanagement Systeme Siehe: Workflow Management Coalition, http://www.wfmc.org/standards/docs/tc003v11.pdf 14 Software Engineering | RWTH Aachen Was haben wir gelernt? Entwurf Entwurfsprozess Guter Entwurf Aufteilen des Problems Hohe Kohäsion Grobentwurf: Wenig Kopplung Subsysteme, Architektur, Subsysteme Schnittstellen, und Schnittstellen Komponenten Wiederverwendung: Feinentwurf: Komponenten, Frameworks, Datenstrukturen, Referenzmodelle, Algorithmen Referenzarchitekturen 15 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, Analyse Entwurf Wartung 6. Software- & Systementwurf tierung Integration 6.2. Softwarearchitektur Grobentwurf Feinentwurf Prof. Bernhard Rumpe Literatur: Sommerville 10 Software Engineering Balzert LE 23 RWTH Aachen Shaw/Garlan: Software Architecture, 1996 Bass/Clements/Kazman: Software Architecture in Practice, Addison-Wesley, 1998 P. Kruchten, The 4+1 view model of architecture, IEEE Software, Nov. 1995, 12(6) http://www.se-rwth.de/ Von der Analyse zum Entwurf Analyse Anforderungs- Funktionale Anforderungs- Spezifikation Spezifikation Ermittlung (Pflichtenheft) (Produktdefinition) System- Modellierung Architektur- Spezifikation Architektur- Entwurf Entwurf Detail- Entwurf Klassen- bzw. Modul- Spezifikationen 17 Software Engineering | RWTH Aachen Was ist Architektur? „[Architektur ist] Harmonie und Einklang aller Teile, die so erreicht wird, dass nichts weggenommen, zugefügt oder verändert werden könnte, ohne das Ganze zu zerstören.“ [Leon Battista Alberti] https://xkcd.com/ 18 Software Engineering | RWTH Aachen Softwarearchitektur: Definitionen aus der Literatur “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.” [BCK03] “Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.” [IEEE Std. 1471-2000] 19 Software Engineering | RWTH Aachen Softwarearchitektur: Unsere Sicht Softwarearchitektur beschreibt die Struktur eines Systems. Diese Beschreibung beinhaltet - die Komponenten, - deren Schnittstellen - und deren Beziehungen Sie beschreibt die wichtigsten strukturellen Eigenschaften eines Systems präzise, ist gleichzeitig aber kompakt. Sie beinhaltet die essentiellen Eigenschaften eines Systems, die sich auf Gesamtsystemsicht beschreiben und analysieren lassen 20 Software Engineering | RWTH Aachen Stakeholder Ein System wird von vielen Faktoren beeinflusst - Kunden - Endnutzer - Entwickler - Projektmanager - Wartungspersonal (Konfiguration, Weiterentwicklung) - Vermarktung/Verkauf - … Diese werden als Stakeholder bezeichnet: Stakeholder Alle am Projekt direkt oder indirekt beteiligten Personengruppen 21 Software Engineering | RWTH Aachen  Einfluss der Stakeholder auf die Softwarearchitektur Wartungsteam Kunde Modifizierbarkeit, Niedrige Kosten, Erweiterbarkeit Niedrige Kosten, schnelle EntwicklerInnen Auslieferung, kaum Management gleichmäßig Nachbesserungen Entwicklungsteam auslasten ?? Time to Market, Features, Performance, Abgrenzung zu Sicherheit, Konkurrenz- produkten, Verlässlichkeit, Kundenspezifische Nutzbarkeit Anpassbarkeit Marketing Nutzer Softwarearchitekt Abbildung [BCK03] nachempfunden 22 Software Engineering | RWTH Aachen Nutzen einer Architekturbeschreibung Kommunikation der Stakeholder Wiederverwendbare Abstraktion des Systems - gemeinsame Sprache - Produktlinien haben gemeinsame Architektur - Abstraktion macht überhaupt Kommunikation möglich - Wiederverwendung von Komponenten - Schulung der Entwickler - Wiederverwendung von erprobten Designs Wesentliche Entwurfsentscheidungen Fokus auf spezifische Systemeigenschaften möglich - Beschränkung der Implementierungsmöglichkeiten - Getrennte Betrachtung der Aspekte - Legt Organisationsstruktur fest - Trennung der Zuständigkeiten - Verhindert oder erlaubt bestimmte Stufen für - Übersichtlichkeit Qualitätsattribute - Erlaubt das Urteilen über und Verwalten von Frühzeitige Analysemöglichkeiten Veränderungen - Prototypen - Zeit und Kostenschätzung - Risikoabschätzung - Zeit- und Kostenschätzung - Vorhersage von Eigenschaften des Systems 23 Software Engineering | RWTH Aachen Architektur-Beispiel Physikalische Architekturen Drucker Netzwerkdrucker Dateisystem Netzwerk Architektur Stand-alone Druck- Service Architektur Anwendung File- Anwendung Service Netzwerk Dateiserver Anwendung Anwendung 24 Software Engineering | RWTH Aachen Architektur-Beispiel Physikalische Architekturen - Client - Firewall - Applikationsserver - Daten 25 Software Engineering | RWTH Aachen Architektur-Beispiel Schichten Architektur der Software (innerhalb eines Systems): 26 Software Engineering | RWTH Aachen Architektur der Energie Navigator Plattform (der Synavision GmbH) optional Data Import Preprocessing Analysis Reporting standard. Building filter types userdefined automatic rule based reporting scale outlier normalization detection manual counter equidist. pattern based expert comments interpolation timesteps User visualisation Specification data export § carpet plots rules functions § line plots § scatter plots characteristics metrics § performance ticket system charts Expert time routines facility architecture DBS 27 Software Engineering | RWTH Aachen Architektur der Energie Navigator Plattform: Componenten ena-backup client docu-plugin ena-backup- ena-docu- ena-backup-service ena-client interface mentation ena-web ena-web ena-backup- ena-backup- ena-document.- ena-visual transformation transformation dev.App ena-visual-service ena-import-ejb ena-core sse-util ena-reporting ena-import-domain ena-domain ena-algorithms sse-util ena-import-service ena-dependency- ena-ejb-api manager Postgres ena-management ena-ejb ena-lang ena-user- ena-resy ena-accounting-logic management- service ena-report- ena-dataimport ena-resy generator ena-accounting- ena-user- domain management-logic ena-user- ena-storage management ena-storage-webservice HDF5 ena-storage ena-storage-logic Postgres 28 Software Engineering | RWTH Aachen Architektur von Assistenzsystemen zur menschlichen Handlungsunterstützung Model-Centered Architecture (MCA) - Modeling Tool: CRUD models - Model Transfer Interface & Model Adapter: providing models to the consumer system - Model Storage and Model Storage Manager for model persistence - Data Transfer & Data Adapter: conversion of external data into internal representation - Model & Data Storage - Model Consumer: components using models to provide the functionality of the MCA-based solution - Device and User Interface: model-based interfaces to the model consumers 29 Software Engineering | RWTH Aachen Architektur von Assistenzsystemen: Konkretes Beispiel MCA Architektur angewandt für eine konkrete Anwendung Projekt: Human Behavior Monitoring and Support (HBMS) 30 Software Engineering | RWTH Aachen Caroline‘s Kommunikationsarchitektur Video: https://www.youtube.com/watch?v=aHYRtOvSx-M 31 Software Engineering | RWTH Aachen Caroline‘s Physische Komponenten-Architektur 32 Software Engineering | RWTH Aachen Architektur-Beispiel Joint JointForces Kommunikationsarchitektur Global Forces Challenge Global InfoGrid Info Grid eines is to make this Software-Intensiven possible! Systems mit Echtzeitanforderungen: Adapted from “The Future of AWACS”, by LtCol Joe Chapa 33 Software Engineering | RWTH Aachen Conway's Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvin Conway, 1968 How to get a better architecture? Inverse Conway Maneuver: alter the development team's organization structure to encourage the desired software architecture -- Martin Fowler, 2022 34 Software Engineering | RWTH Aachen Conway's Law, some “Examples” : 35 Software Engineering | RWTH Aachen Conway's Law, some “Examples” : 36 Software Engineering | RWTH Aachen Analogie: Hausbau Ein Haus lässt sich durch verschiedene Pläne beschreiben: - Grundriss - Aufriss - Lageplan - Elektrischer Anschlussplan - Kanalisation -… Jeder Plan - hat eine bestimmte Aufgabe - stellt einen Ausschnitt des Hauses dar - hat unterschiedliche Zielgruppen 37 Software Engineering | RWTH Aachen Sicht Eine Sicht ist eine Darstellung eines Systems, die nur die Elemente und Beziehungen enthält, die für eine bestimmte Perspektive relevant sind. Verschiedene Sichten bilden eine Gesamtspezifikation Herausforderungen: - Konsistenz zwischen Sichten - Vollständigkeit - Möglichkeit zur Abstraktion - Übersichtlichkeit der Darstellung - Realitätstreue der Sicht - Beschreibungssprachen 38 Software Engineering | RWTH Aachen „4+1 Sichten“-Modell der Softwarearchitektur (aus dem Rational Unified Process - RUP) Logische Sicht Struktursicht Szenarien Ablaufsicht Physikalische Sicht Philippe Kruchten, The 4+1 view model of architecture, IEEE Software, November 1995, 12(6), pp. 42-50 39 Software Engineering | RWTH Aachen Modellierungstechniken und Kern-Elemente der 4+1 Sichten Logische Sicht Struktursicht Klassenmodell Subsysteme Verfeinerung des Schnittstellen Analysemodells Szenarien Use-Cases Grobentwurf Ablaufsicht Physikalische Sicht Prozesse Komponenten Koordination Hardwaresysteme Netze Feinentwurf 40 Software Engineering | RWTH Aachen Primäre Zielgruppe/Aufgabe jeder der vier Sichten Logische Sicht Struktursicht Endanwender Programmierung Wartung Grobentwurf Ablaufsicht Physikalische Sicht System-Integratoren Kommunikation (Performanz, Verteilung Durchsatz...) Auslieferung, Installation Feinentwurf 41 Software Engineering | RWTH Aachen Blockdiagramme Blockdiagramme sind ein verbreitetes Hilfsmittel zur Skizzierung der logischen Struktur einer Systemarchitektur. Subsystem umfasst Objekte bestimmter Klassen Schnittstelle ist klar definiert (Aufrufschnittstelle, Kommunikationsprotokoll) Schnittstelle Umfassendes Subsystem Subsystem 42 Software Engineering | RWTH Aachen UML: Implementierungsdiagramm Zusammengesetzte Komponente Komponente D A Schnittstelle D B C A entspricht diesem Blockdiagramm B C 43 Software Engineering | RWTH Aachen Konfigurationsdiagramme Konfigurationsdiagramme sind das meistverbreitete Hilfsmittel zur Beschreibung der physikalischen Verteilung von System-Komponenten. Rechner, Knoten Datenkommunikations- Speicherndes Netz Lokales Kommunikationsnetz System 44 Software Engineering | RWTH Aachen UML: Verteilungsdiagramm engl.: deployment diagram zeigt die physische Verteilung von Systemen Stereotypen kennzeichnen Node die Arten von Knoten (Knoten) Client LAN Server 1 Server 2 Komponenten können zugeordnet werden A B 45 Software Engineering | RWTH Aachen Beispiel Terminverwaltung PC1... PCn Tablet... 1 Smartphonem Physikalische Konfiguration Termin- Anzeigetafel- Server Steuerung PC Client PDA Client Blockdiagramm PDA Sync Daten- Termin-Manager Export Termin-Datenbank 46 Software Engineering | RWTH Aachen Was haben wir gelernt? Software- Software- architektur… architekt Nutzen …beschreibt die Struktur …kann eine Person oder Kommunikation mit eines Systems ein Team sein Stakeholdern … besteht aus … hat und braucht viel Wesentliche Komponenten, Erfahrung Entwurfsentscheidungen Schnittstellen und Beziehungen Wiederverwendbare …muss zwischen Abstraktion Essenzielle unterschiedliche Eigenschaften; Stakeholder-Interessen Fokus auf spezifische abstrahiert von Details ausgleichen Systemeigenschaften Unterschiedliche Sichten Frühzeitige Analyse möglich 47 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, Analyse Entwurf Wartung 6. Software- & Systementwurf tierung Integration 6.3. Taktiken im Softwareentwurf Grobentwurf Feinentwurf Prof. Bernhard Rumpe Literatur: Software Engineering Sommerville 10 RWTH Aachen Balzert Band I LE 23 Balzert Band II LE 17 Bass, Clements and Kazman (2003) Software Architecture in Practice http://www.se-rwth.de/ Taktiken („Kleine Methodiken“) Taktik - Technik die Stufe eines Qualitätsattributs in einem System zu verändern - kann durch spezifischere Taktiken verfeinert werden - wird typischerweise durch Muster realisiert Sammlung von Taktiken für einzelne Qualitätsattribute möglich Bieten Vokabular für die Auswirkungen des Einsatzes von Mustern auf das Systemverhalten [BCK03] enthält Sammlung von Taktiken für - Verfügbarkeit - Modifizierbarkeit Beispiele - Performance - Security - Testbarkeit - Usability 49 Software Engineering | RWTH Aachen Problem: Verfügbarkeit Begriffsbildung: - Failure § Von außen beobachtbarer Fehler eines Systems Failure n Failure n+1 § ggf. mehrere Faults resultieren in einem Failure - Fault § Intern aufgetretener Fehler § Kann korrigiert werden oder wird zum Failure MTR MTF Mean Time to Repair (MTR) = Durchschnittliche Zeit zur Reparatur eines Failures Mean Time to Failure (MTF) = Durchschnittliche Zeit zwischen zwei Failures (Ohne Absichtliche Down-Zeiten) Verfügbarkeit = MTF/(MTF+MTR) Geplante Wartungsarbeiten werden nicht gerechnet. 50 Software Engineering | RWTH Aachen Taktiken für Verfügbarkeit | 1 Fehlererkennung (Fault) - Exception § Delegation der Fehlerbehandlung an eine Fehlerbehandlungskomponente - Ping/Echo § Eine Komponente pingt alle anderen in regelmäßigen Abständen an und kontrolliert die Antworten - Heartbeat § Komponenten müssen sich regelmäßig melden § Vorteilhaft falls bereits regelmäßige Kommunikation stattfindet 51 Software Engineering | RWTH Aachen Taktiken für Verfügbarkeit | 2 Fehlerbehandlung (Fault) - Abstimmen § Möglich bei redundanten Systemen - Aktive Redundanz § Redundante Komponenten laufen parallel und sind beide aktiv § Bei Ausfall einer Komponente bleibt das System lauffähig - Passive Redundanz § Nur eine Komponente interagiert mit der Umgebung § Die übrigen werden fortlaufend auf den neusten Stand gebracht § Bei Ausfall übernimmt eine passive Komponente die aktive Rolle - Spare § Redundantes System, das mehrere Komponenten übernimmt § Kann eine Rolle dynamisch übernehmen 52 Software Engineering | RWTH Aachen Beispiel: Heartbeat + Redundanz Monitor und Auswahl haben zusätzlich eine einfache Steuerungsfunktion Beispiel: Motorsteuerung Motorsteuerung Monitor Reset Failure- Mode Heartbeat Komplexe Steuerung Aktoren Auswahl Sensoren Einfache Steuerung 53 Software Engineering | RWTH Aachen Taktiken für Verfügbarkeit | 3 Redundante Komponente wiedereinführen (nach Abschaltung durch Failure) - Schattenoperation § Komponente mit Failure beobachtet zunächst das System § vergleicht Verhalten mit redundanten Komponenten § kehrt nach kurzer Zeit in den Betrieb zurück - Zustands-Resynchronisation der redundanten Komponenten § Komponenten zurücksetzen, upgrade auf den aktuellen Zustand § Kopie von redundanten Systemen § kann sehr aufwändig sein, wenn das Synchronisationsprotokoll komplex ist - Checkpoint/Rollback § Periodisch wird ein Checkpoint erstellt § In diesen Zustand kann das System zurückgesetzt werden (Rollback) 54 Software Engineering | RWTH Aachen Problem: Modifizierbarkeit Modifizierbarkeit - Messbar durch Zeit bzw. Kosten für § die Implementierung § das Testen § Ausliefern von Änderungen - wird erschwert durch § die Abhängigkeit von Komponenten untereinander § fehlende Lokalisierung von Funktionalität Quelle: [BCK03] „Ripple-Effekt“ - Änderungen an anderen Komponenten, die indirekt notwendig werden, weil eine Komponente anzupassen ist. 55 Software Engineering | RWTH Aachen Taktiken für Modifizierbarkeit | Reduktion der betroffenen Komponenten Kapselung (hohe Kohäsion) - Möglichst wenig öffentliche Schnittstellen - Private Methoden können leicht geändert werden (d.h. sind ohne Auswirkung auf andere Komponenten) Verbindungen reduzieren (geringe Kopplung) - Weniger Komponenten werden beeinflusst Vorhandene Schnittstellen erhalten - Neue Schnittstellen nur zusätzlich einführen - Gefahr: § Komplexer werdendes System § Spätere Änderungen aufwändiger (vgl. Agile Methoden und Simplicity-Prinzip, vgl. @deprecated) Vermittler (Broker) - Je nach Verbindungstyp, z.B. § Bus statt direkter Verbindung § Ort der Komponenten: Namensdienste § Entwurfsmuster Fassade, Adapter, Mediator 56 Software Engineering | RWTH Aachen Taktiken für Modifizierbarkeit | Reduktion der notwendigen Änderungen Kohärenz erhalten gut sind: - Eine Aufgabe wird durch genau eine Komponente erfüllt - Die Realisierung eines Dienstes ist nicht über das System verteilt Änderungen antizipieren - Mögliche Änderungen gedanklich durchspielen (nicht implementieren! vgl. XP-Grundsätze) - Dabei Fragen beantworten: § Betreffen fundamental unterschiedliche Änderungen dasselbe System? § Betrifft eine Änderung mehrere Komponenten? - Falls ja, deutet das auf mangelnde semantische Kohärenz hin 57 Software Engineering | RWTH Aachen Taktiken für Modifizierbarkeit | Verzögern des Bindungs-Zeitpunkts Registrierung zur Laufzeit - Plug-In-Fähigkeit von Komponenten Konfigurationsdateien - Konfiguration bei Auslieferung oder Rekonfiguration zur Laufzeit Polymorphie - Erlaubt das Ersetzen durch abgeleitete Klassen/Komponenten (zur Laufzeit) Komponentenersetzung - Dynamisches Zusammenstellen der Anwendung bei Auslieferung Standardisierte Protokolle - Erlauben die Kooperation unabhängiger Prozesse 58 Software Engineering | RWTH Aachen Modifizierbarkeit | The Dependency Inversion Principle 1) High-Level-Komponenten sollen nicht von Low-level-Komponenten abhängen. Beide sollen nur von Abstraktionen (Interfaces) abhängig sein. 2) Abstraktionen sollen nicht von Details abhängen, sondern die Details von den Abstraktionen nicht so «interface» A benutzt A benutzt F sondern so B B Vorteile: - Anpassungen unten beeinflussen obere Ebenen nicht! - leichtere Modifizierbarkeit und Testbarkeit Robert C. Martin: The Dependency Inversion Principle. 1996 59 Software Engineering | RWTH Aachen  Problem: Software Security “Software Security is the idea of engineering software so that it continues to function correctly under malicious attack.” [Mc Graw] Eine Schutzmaßnahme schützt vor einem oder mehreren Angriffen - es gibt nicht die „Silver Bullet“ - Häufige Fehleinschätzung: „Wir haben eine Firewall also sind wir sicher.“ - Firewall schützt auf Netzwerkebene nicht gegen Angriffe auf Applikationsebene wie SQL Injection Auswahl der richtigen Schutzmaßnahmen, die vor einer Bedrohung schützen Nur wenige Schutzmaßnahmen lassen sich kapseln z.B. Verschlüsselung McGraw, Gary. Software security: building security in. Addison-Wesley Professional, 2006 60 Software Engineering | RWTH Aachen Liste von Taktiken für Security Securing the Weakest Link Earn or give, but never assume, trust. Defense in Depth Beispiele Failing Securely Strictly separate data and control instructions, and Least Privilege never process control instructions received from untrusted sources Separation of Privilege Economy of Mechanism Define an approach that ensures Least Common Mechanism all data are explicitly validated Reluctance to Trust Never Assuming that your Secrets are Safe Understand how integrating external components Complete Mediation changes your attack surface Psychological Acceptability... Promoting Privacy http://cybersecurity.ieee.org/center-for-secure-design/avoiding-the-top-10-security-flaws.html https://buildsecurityin.us-cert.gov/articles/knowledge/principles/design-principles 61 Software Engineering | RWTH Aachen Taktiken für Security | 1 Securing the Weakest Link Sicherheitsmaßnahmen ergeben eine Kette, die nur so stark ist wie ihr schwächstes Glied Angreifer greifen dort an, wo der Widerstand am geringsten ist Taktik: Schwächste Stelle des Gesamtsystems identifizieren Dort Sicherheitsmaßnahmen einbauen Failing Securely Standardmäßig Zugriff verweigern, Benutzern explizit Zugriff gewähren Im Fehlerfall keine (unsicheren) Aktionen zulassen 62 Software Engineering | RWTH Aachen Taktiken für Security | 2 Economy of Mechanism Fehler in Sicherheitsmaßnahmen fallen im normalen Gebrauch und bei funktionalen Tests nicht auf. Daher notwendig: Aufwändiges Code Review, Sicherheitstests (Penetrationstests), u.U. Beweis von privacy Eigenschaften Taktik: Keep it simple (KISS) Sicherheitsmechanismen (Verschlüsselung, Authentisierung) wiederverwenden (nicht selbst implementieren) Least Privilege Jeder Benutzer/Funktion bekommt nur die für ihre Arbeit notwendigen Rechte/Ressourcen Ergebnis: Übernimmt ein Angreifer die Kontrolle über die Funktion sind die Auswirkungen geringer 63 Software Engineering | RWTH Aachen Was haben wir gelernt? Taktiken… Qualitätsattribute Einsatz …sind Techniken um die Verfügbarkeit, z.B. Betrachtung nicht- Stufe eines Heartbeat und funktionaler Anforderung Qualitätsattributs in Redundanz einem System zu Realisierung von verändern Modifizierbarkeit, z.B. Taktiken für die Verbesserung der …werden oft mit Mustern Dependency Inversion Systemarchitektur realisiert Performance Sammlungen bieten ein Security, z.B. securing Vokabular für die Auswirkungen des the weakest link, KISS Einsatzes von Mustern Testbarkeit auf das Systemverhalten Usability, etc. 64 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, Analyse Entwurf Wartung 6. Software- & Systementwurf tierung Integration 6.4. Objektorientierter Feinentwurf mit Klassendiagrammen Grobentwurf Feinentwurf Prof. Bernhard Rumpe Software Engineering RWTH Aachen http://www.se-rwth.de/ Warum, was, wie und wozu? Feinentwurf Warum? Was? Wie? Wozu? Mehr fachliche Details Schritt zwischen z.B. Vollständigkeit, Architektur und Klassendiagramme Sichtbarkeiten und Implementierung Datentypen, Navigationsrichtung,… Basis für die Entwicklung des Systems Zusätzliche technische Effizienz kommt von Verfeinerung des Klassen/Pakete z.B. guter Planung Analysemodells Plattformabhängig 66 Software Engineering | RWTH Aachen Objektorientierter Feinentwurf Ausgangspunkt: - Grobdefinition der Architektur: § Zerlegung in Subsysteme (evtl. unter Verwendung von Standardarchitekturen) § Verteilungskonzept § Ablaufmodell Ergebnis des Feinentwurfs: - OO-Modell für jedes Subsystem der Architektur - OO-Modell für unterstützende Subsysteme § unter Berücksichtigung gewählter Technologien - Spezifikationen der Klassen - Spezifikationen von externen Schnittstellen 67 Software Engineering | RWTH Aachen Verfeinerung und Umbau des Analysemodells K Fachlicher Kern: Mehr Details als im Analysemodell abc - Listen der Attribute und Operationen: (einigermaßen) vollständig xyz - Attribute und Operationen: Datentypen, Sichtbarkeit abra - Operationen: Spezifikation (z.B. Vor- und Nachbedingungen) kadabra - Assoziationen/Aggregationen: Navigationsrichtung, Ordnung, Qualifikation Zusätzliche "technische" Klassen/Pakete: - Einbindung in Infrastruktur, Frameworks, Altsysteme etc. - Anpassungs- und Entkopplungsschichten für gewählte Technologien K (z.B. Datenzugriffsschicht, CORBA-Schnittstellen, XML- T1 abc T2 xyz Anschluss...) T2 abra (T1 x) T3 kadabra (T2 y) 68 Software Engineering | RWTH Aachen UML im Entwurf Requirements Generell: Analysemodelle werden im Entwurf umgebaut Insbesondere Klassendiagramme erhalten dazu eine neue Bedeutung: - In der Analyse repräsentieren Klassen Dinge der realen Welt - Im Entwurf stellen Klassen einen Teil des Softwaresystems dar - Es findet eine Detaillierung und Präzisierung statt T T T T Statecharts werden detailliert oder ein Einzelspezifikationen von Methoden zerlegt T Andere UML-Diagramme werden im Feinentwurf vor allem als T T T Vorlagen (Aktivitäts-, Sequenzdiagramme, Use Cases) oder zur Strukturierung im Grobentwurf (Komponentendiagramme) eingesetzt, selbst aber eher nicht weiter detailliert. system 69 Software Engineering | RWTH Aachen UML zum logischen Detailentwurf Analyse-Modell Entwurfs-Modell Notation: UML Notation: UML Objekte: Fachgegenstände Objekte: Softwareeinheiten Klassen: Fachbegriffe Klassen: Schemata Vererbung: Begriffsstruktur Vererbung: Programmableitung Annahme perfekter Technologie Erfüllung konkreter Rahmenbedingungen Funktionale Essenz Gesamtstruktur des Systems Völlig projektspezifisch Ähnlichkeiten zwischen verwandten Projekten Grobe Strukturskizze Genaue Strukturdefinition Mehr Struktur & mehr Details 70 Software Engineering | RWTH Aachen Pakete und Subsysteme UML: - Pakete als „Ordner“ - “Subsystem”: Paket zur Realisierung einer Einheit der Architektur Benutzungs- Java-Sprachkonstrukt: package Schnittstelle Fachliches «use» Modell Terminkalender Termin Besprechungsraum Privattermin Teambesprechung Teammitglied «use» Daten- Verwaltung Aufruf- & Nutzungs- Beziehung 71 Software Engineering | RWTH Aachen Sichtbarkeit Benutzes Sichtbarkeits-Symbol … UML + # – Java / C++ public protected private (default) … führt zu Sichtbarkeit für: Java C++ UML, class C++ struct Gleiche Klasse ja ja ja ja ja ja Andere Klasse, gleiches Paket ja ja/nein1 nein ja nein2 ja2 Andere Klasse, anderes Paket ja nein nein nein nein2 ja2 Unterklasse, gleiches Paket ja ja nein ja nein2 ja2 Unterklasse, anderes Paket ja ja nein nein nein2 ja2 1 In Java „ja“, in UML und C++ „nein“ 2 In C++ default bei Klassen: private, bei struct: public 72 Software Engineering | RWTH Aachen Qualifizierte Assoziation (Erinnerung) Definition: Eine Qualifikation (Qualifier) ist ein Attribut für eine Assoziation zwischen Klassen K1 und K2, durch das die Menge der zu einem K1-Objekt assoziierten K2-Objekte partitioniert wird. Zweck der Qualifikation ist direkter Zugriff unter Vermeidung von Suche. Notation: 0..1 K1 a K2 als Detaillierung von: 0..* K1 K2 Bedeutung vor allem im Zusammenhang mit Datenbanken (Schlüssel, Indizes in Look-up Tabellen), aber auch mit geeigneten Datenstrukturen nach Java abbildbar. - Qualifizierung wird oft erst im Design eingeführt 73 Software Engineering | RWTH Aachen Geordnete und sortierte Assoziation (Erinnerung) 0..* Teilnahme 0..* Teammitglied Teambesprechung {ordered} {ordered} an einem Assoziationsende: - Es besteht eine feste Reihenfolge, in der die assoziierten Objekte durchlaufen werden können - Oft ist Zugriff über Listen, Iteratoren möglich Default: die assoziierten Objekte sind als Menge strukturiert. Weitere Einschränkungen möglich, z.B. die Forderung nach Sortierung gemäß bestimmter Attribute: 0..* 0..* Teammitglied Teambesprechung Teilnehmer Besprechungen {sorted} {order = ascending} 74 Software Engineering | RWTH Aachen Verwaltungsklassen: Singletons Ein Singleton ist eine Klasse, die genau einmal instantiiert wird, zB Verwaltung kann damit gut modelliert werden Termin {abstract} «singleton» title Raumverwaltung beginn dauer freienRaumSuchen() verschieben() {abstract} 1 bestand * {sorted} Teambesprechung Besprechungsraum themen 0..* 0..1 raumNr raumFestlegen() kapazität Veranstaltungsort einladen() reservieren() absagen() freigeben() verschieben istFrei() 75 Software Engineering | RWTH Aachen Abgeleitete (redundante) Elemente Definition: Ein abgeleitetes Modellelement (z.B. Attribut, Assoziation) ist ein Modell-Element, das aus anderen Elementen rekonstruiert werden kann. Notation: / Modellelement oder Modellelement {derived} Beispiele: * Leitung 1 Teambesprechung Teammitglied / teilnehmerzahl name / leiter * Teilnahme 2..* … {leiter = Leitung.name} {teilnehmeranzahl = Teilnahme.size} Ableitung kann mit der Object Constraint Language OCL, ein weiterer Teil der UML, formuliert werden. 76 Software Engineering | RWTH Aachen Parameter und Datentypen für Operationen Analysephase: Besprechungsraum - oft Operationsname ausreichend raumNr - ggf. Parameternamen ohne weitere Information kapazität reservieren() freigeben() istFrei() Entwurfsphase: - Parameter und Datentypen der Operationen genau festlegen! - Sichtbarkeiten Standard-Style Java, C, C++-Style: - istFrei(beginn: Date, dauer: int):boolean - boolean istFrei(Date beginn, int dauer) + reservieren (für: Termin):boolean + boolean reservieren (Termin für) 77 Software Engineering | RWTH Aachen Spezifikation von Operationen Definition: - Die Spezifikation einer Operation legt das Verhalten der Operation fest, ohne einen Algorithmus festzuschreiben. Grundprinzip: Es wird das „Was“ beschrieben und noch nicht das „Wie“. Häufigste Formen von Spezifikationen: - Text in natürlicher Sprache (oft mit speziellen Konventionen) § Oft in Programmcode eingebettet (Kommentare) § Werkzeugunterstützung zur Dokumentationsgenerierung, z.B. “Javadoc” - Vor- und Nachbedingungen - Tabellen, spezielle Notationen - „Pseudocode“ (Programmiersprachenartiger Text) § nur mit Vorsicht zu verwenden - oft zu viele Details festgelegt! 78 Software Engineering | RWTH Aachen Schnittstellen („Interface”) und abstrakte Klassen Abstrakte Klasse Schnittstelle Enthält Attribute und Operationen Enthält nur Operationen (und ggf. Konstante) Kann Default-Verhalten festlegen Kann (seit Java 8) Default-Verhalten festlegen Default-Verhalten kann in Unterklassen Unterklassen müssen Verhalten definieren redefiniert werden Java: Unterklasse erbt nur von einer Klasse; Java, C++: Eine Klasse kann mehrere C++: von mehreren Schnittstellen implementieren Schnittstelle ist eine spezielle Sicht auf eine Klasse 79 Software Engineering | RWTH Aachen Zusammenfassung: UML-Klassenmodelle in Analyse und Entwurf Analyse-Modell Entwurfs-Modell Skizze: Teilweise unvollständig Vollständige Angabe aller in Attributen und Operationen Attribute und Operationen Datentypen und Parameter Vollständige Angabe von können noch fehlen Datentypen und Parametern Noch kaum Bezug zur Auf Umsetzung in gewählter Realisierungssprache Programmiersprache bezogen Keine Überlegungen zur effizienten Navigationsangaben, Qualifikation, Realisierung von Assoziationen Ordnung, Verwaltungsklassen Entscheidung über Datenstrukturen Anbindung von Benutzungsoberfläche und Datenhaltung an fachlichen Kern 80 Software Engineering | RWTH Aachen Was haben wir gelernt? Feinentwurf Entwurfsmodell Details zu… Mehr Details im Klassen stellen einen Paketen und Subsystemen fachlichen Kern Teil des Sichtbarkeiten, Parameter Zusätzliche Klassen und Softwaresystems dar und Datentypen Pakete: Verwendung als Abgeleitete Elemente Einbindung in Grundlage für die Infrastruktur, Implementierung Spezifikation von Frameworks, Operationen Altsysteme etc. Assoziationen (qualifiziert, Anpassungs- und geordnet, sortiert) Entkopplungsschichten Verwaltungsklassen für gewählte (singletons) Technologien abstrakte Klassen und Interfaces 81 Software Engineering | RWTH Aachen Softwaretechnik Implemen- Test, Analyse Entwurf Wartung 6. Software- & Systementwurf tierung Integration 6.5. Entwurf von Nutzeroberflächen Grobentwurf Feinentwurf Prof. Bernhard Rumpe Literatur: Software Engineering Sommerville, I.: Software Engineering, Kap.16 RWTH Aachen Shneiderman, B.: Designing the User Interface: Strategies for Effective Human-Computer Interaction. 1998 Balzert, LE 16 Software-Ergonomie http://www.se-rwth.de/ Warum, was, wie und wozu? Entwurf von Nutzeroberflächen Warum? Was? Wie? Wozu? Entwurfsgrundsätze In der Praxis werden Nutzeroberflächen Selbst konkret anwenden Interaktionsarten in eigenen Projekten immer wichtiger Entwurf von Nutzeroberflächen Darstellung von Information Überlegungen in der Aktivitäten des Entwurfs Grundwissen über Entwurf frühen Entwurfsphase von Oberflächen Benutzerfreundlichkeit 83 Software Engineering | RWTH Aachen Entwurf von Oberflächen Entwurf von Systemen Menschliche (Un-)Fähigkeiten bedenken - Architektur | Schnittstellen | Komponenten | Daten | … | Kurzzeitgedächtnis Hardware - ca. 7 einzelne Informationen zu gleich erinnerbar - Entwurf der Oberflächen - à Nicht zu viel Information auf einmal anzeigen Graphische Oberflächen Alle machen Fehler - Viele unterschiedliche Technologien und Frameworks - Gründe: zu viel Information zur gleichen Zeit, - Unterschiedliche Hardware gesundheitliche Einschränkungen, Stress - Warnmeldungen bei Systemfehlern erhöhen den Stress Faktor Mensch - Wichtiges identifizieren - Fähigkeiten, Erfahrungen und Erwartungen der Benutzer Unterschiedliche körperliche Fähigkeiten - Sehkraft | Gehör | Erkennen von Farben | Motorische Spannungsfeld Fähigkeiten - Benutzerfehler vs. Fähigkeiten und Arbeitsumgebungen - Entwurf nicht an den eigenen Fähigkeiten ausrichten der Benutzer in der Entwicklung nicht bedacht - Unterstützung vs. Behinderung von Tätigkeiten Unterschiedliche Vorlieben bei der Interaktion - Bildschirm | Text - Direkte Bearbeitung | Befehle geben 84 Software Engineering | RWTH Aachen  Wiederholung Herausforderungen Quelle: https://www.conversationagent.com/2010/01/what-really-affects-behavior.html 85 Software Engineering | RWTH Aachen Kognitiv gut erfassbar? 86 Software Engineering | RWTH Aachen Entwurfsgrundsätze Benutzervertrautheit - Bezeichnungen und Begriffe aus der Erfahrungswelt der Nutzer, die am meisten vom System gebrauch machen - Domänenspezifische Sprachen helfen Konsistenz - Vergleichbare Operationen gleich veranlasst Minimale Überraschung - Keine Überraschung durchs Systemverhalten Wiederherstellbarkeit - Mechanismen zur Wiederherstellung bereitstellen Benutzerführung - Bei Fehlern aussagekräftige Rückmeldungen & kontextsensitive Hilfsmittel Benutzervielfalt - Geeignete Interaktionsmöglichkeiten für verschiedene Arten von Systembenutzern 87 Software Engineering | RWTH Aachen Entwurfsfragen Wie sollen Benutzer mit dem System interagieren? Wie sollen Informationen des Systems den Benutzern dargestellt werden? 88 Software Engineering | RWTH Aachen Interaktionsarten Direkte Manipulation - Direkte Interaktion mit Objekten auf dem Bildschirm - Beteiligte: Zeigegerät (z.B. Maus, Finger bei Touchscreens), zu bearbeitendes Objekt, Aktion die erfolgen soll Menüauswahl - Befehl aus einer Liste aller Möglichkeiten auswählen - Kombination mit direkter Manipulation: Objekt auswählen, auf die sich der Befehl dann auswirkt Ausfüllen einer Eingabemaske - Felder ausfüllen - Kombination mit Menüs, Buttons Befehlssprache - Spezieller Befehlt mit Parametern Natürliche Sprache - Meist Frontend für eine Befehlssprache - Analyse der natürlichen Sprache und Übersetzung in einen Systembefehl 89 Software Engineering | RWTH Aachen Vor- und Nachteile der Interaktionsarten Art der Wichtigste Vorteile Wichtigste Nachteile Anwendungsbeispiele Interaktion Direkte Schnelle und intuitive Möglicherweise schwierig zu implementieren Videospiele Manipulation Interaktion Nur angemessen, wenn es optische CAD-Systeme Leicht zu erlernen Metaphern, Aufgaben und Objekte gibt Menüauswahl Verhindert Benutzerfehler Für erfahrene Benutzer zu langsam Die meisten allgemein Wenig Tippen erforderlich Kann komplex werden, wenn viele eingesetzten Systeme Menüoptionen vorhanden sind Ausfüllen einer Einfache Dateneingabe Benötigt viel Platz auf dem Bildschirm Die meisten allgemein Eingabemaske Leicht zu erlernen Führt zu Problemen, wenn die eingesetzten Systeme Überprüfbar Benutzeroptionen nicht mit den Formularfeldern übereinstimmen Befehlssprache Leistungsfähig und flexibel Schwer zu erlernen Betriebssysteme, Shells, Schwaches Fehlermanagement Steuerungssysteme Natürliche Zugänglich für Erfordert mehr Tippen / Spracherkennung Systeme zum Abrufen von Sprache Gelegenheitsnutzer Systeme, die natürliche Sprache verstehen, Informationen, SmartHome Leicht erweiterbar sind unzuverlässig 90 Software Engineering | RWTH Aachen Interaktion in der Praxis Gemischte Interaktionsarten - Direkter Zugriff & Menübasiert - Befehlssprache mit speziellen Eingabemasken Individualisierte Oberflächen für unterschiedliche Benutzerklassen - Gelegenheits- und erfahrene Benutzer, z.B. § Betriebssysteme (Befehlssprache vs. graphische Oberflächen) § Suche im Web (Formular inkl. komplexer Befehlssprache) 91 Software Engineering | RWTH Aachen Darstellung von Information Arten der Darstellung Subjekt - Direkte Anzeige der Eingabeinformation, z.B. textuell - Graphische Anzeige A 30 Daten B 40 Richtlinie für den Softwareentwurf C 60 - Trennung der für die Informationsdarstellung Darstellungen erforderlichen Software von den Daten selbst D 50 - à Entkopplung der Darstellung und der Daten 70 30 60 60 50 50 50 60 A 40 40 50 B 40 30 30 40 C 30 20 D 10 60 0 A B C D A B C D 92 Software Engineering | RWTH Aachen MVC-Modell der Benutzerinteraktion Architekturmuster: Model-View-Controller (MVC) § Model Benutzer - Datenhaltung des Systems zeigt an § View interagiert - Sichten auf die Daten (mehrere je Modell) leitet weiter § Controller Controller View - Benutzerschnittstelle und Modifikation der Daten (je View ein Controller zugeordnet) informiert modifiziert fragt an Getrennte Interaktion mit jeder der Darstellungsarten möglich Aktualisierung aller Darstellungen bei Änderungen der Daten Model 93 Software Engineering | RWTH Aachen Darstellung von Information Fragestellungen, z.B. 60 50 Genaue Information oder Beziehung zwischen 40 Datenwerten? 30 Häufigkeit der Veränderung von Informationswerten - Unmittelbare Anzeige dieser Veränderungen? A B C D 70 Maßnahmen durch den Benutzer notwendig bei 60 60 Informationsänderungen? 50 50 40 40 30 30 Direkte Interaktionsmöglichkeit in der Oberfläche 20 oder reine Anzeige? 10 30 0 50 A Art der Information? A B C D B - Text 40 C - Numerische Daten D - Visuelle Graphik 60 - Diagramm (Graph) 94 Software Engineering | RWTH Aachen Informationen, die sich nicht verändern Text Jan Feb Mär Apr Mai Jun - Genaue Angaben erforderlich - Relativ langsame Änderung von Werten 3111 3133 2848 3345 2133 3493 - Pro: geringere Bildschirmfläche - Kontra: nicht auf einen Blick erfassbar 4000 Graphische Darstellung 3000 - Schnelle Änderungen - Nicht genaue Werte sondern Beziehungen zwischen Daten 2000 und Tendenzen im Vordergrund 1000 - Pro: schnellere Erfassung 0 - Kontra: größere Bildschirmfläche, Download/Rendering dauert länger Jan Feb Mär Apr Mai Jun Unterscheidung von dynamischen Daten durch andere Darstellungsart 95 Software Engineering | RWTH Aachen Dynamisch ändernde Informationen Numerische Informationen - Analoge Darstellungen 1 - Bei Bedarf: Ergänzung um eine 0 10 20 4 2 Digitalanzeige 3 Skala mit Zeiger Tortendiagramm Thermometer Horizontaler Balken Kontinuierliche analoge Anzeigen - Relativer Bezug der Werte z.B. zu Maximalwerten Druck Temperatur 0 100 200 300 400 0 25 50 75 100 96 Software Engineering | RWTH Aachen Große Informationsmengen Abstrakte Anzeigeformen Verknüpfung von in Beziehung stehenden Daten Zwei- und Dreidimensionale Darstellung Bäume Netze Karten als Grundlage Bilder: https://www.berliner-zeitung.de/berlin/wechselhafter-fruehlingsbeginn-auf-hoch-hannelore-folgt-tief-jerry-32250088; https://de.wikipedia.org/wiki/Soziale_Netzwerkanalyse#/media/Datei:Social_Network_Analysis_Visualization.png sowie SH: Artefaktmodell 97 Software Engineering | RWTH Aachen Farben Aufwertung von Oberflächen durch Farbe: Komplexität handhaben (ohne zu übertreiben!!!) Richtlinien für wirkungsvolle Verwendung von Farben (Auszug) Anzahl der Farben beschränken & zurückhaltend verwenden - Fenster: 4-5 Farben; Oberfläche: max. 7 Farben Farbänderungen zur Anzeige von Änderungen des Systemzustands - Wichtige Ereignisse markieren | wichtig für Komplexe Anzeigen mit vielen Elementen Farbcodes verwenden um Aufgaben der Benutzer zu unterstützen - Außergewöhnliche Objekte markieren Farbcodes bedacht und konsistent verwenden Weiß - z.B. Rot an einer Stelle für Fehlermeldungen verwendet Rot Sorgsam mit Farbpaaren umgehen Schwarz - Lesbarkeit, Kontrast, Bedeutung unterschiedlich je Kontext [Shneiderman 1998] 98 Software Engineering | RWTH Aachen Entwurf von Systemmeldungen Kontext - Widerspiegelung des aktuellen Benutzerkontexts - Was hat der Benutzer gerade getan, wie hängt die Fehlermeldung damit zusammen Erfahrung - Experten: Irritiert durch lange „bedeutungsvolle“ Meldungen - Anfänger: Problemverständnis schwierig wenn zu kurz und knapp & Technikdetails (z.B. Stack Traces helfen nicht) Fähigkeiten - Zugeschnitten auf Fähigkeiten und Erfahrungen der Benutzer (Terminologie) Stil - Positiv statt negativ | aktiv statt passiv | Nie: verletzend, komisch, sarkastisch 99 Software Engineering | RWTH Aachen  Wiederholung Kap. 2.4 Klassifikation von Prototyping Weiterverwendung Phase im Phasenmodell Zielgruppe des Prototyps (vorwiegend) explorativ wegwerfen Analyse Anwender, Systemanalytiker experimentell wegwerfen (Analyse,) Entwickler Entwurf, Implementierung evolutionär ausbauen Entwickler, Anwender (inkrementelle (sinnvoll nur bei Entwicklung) evolutionärer Entwicklung) 100 Software Engineering | RWTH Aachen Mögliche Vorgehensweise zum Entwurf von Oberflächen AD [nicht ok] Benutzeraktivitäten Papierbasierten Entwurf mit analysieren und Entwurfsprototyp Endbenutzern verstehen erzeugen bewerten [ok] Entwurfsprototyp Anmerkung - Es muss nicht immer ein Papier-basierter oder dynamischer Prototyp existieren [nicht ok] Dynamischen Entwurf mit Entwurfsprototyp Endbenutzern erzeugen bewerten [ok] Ausführbarer Bedienoberfläche Prototyp implementieren [nach Sommerville] 101 Software Engineering | RWTH Aachen Benutzeranalyse Analyse der Benutzeraktivitäten - Siehe UML-Modelle zur Anforderungsermittlung § Use Case § Aktivitätsdiagramme Techniken - Aufgabenanalyse: einzelne Personen - Interviews und Fragebögen: einzelne Personen bzw. Gruppen von Personen - Ethnographische Studien: Interaktion zwischen unterschiedlichen Personen Gesamtbild was Benutzer tun - Durch keine der Methoden erreichbar Ergänzende Ansätze - Rückschlüsse auf Oberfläche - Feedback von Benutzern unbedingt notwendig 102 Software Engineering | RWTH Aachen Erstellen des Systemprototyps Evolutionäre oder explorative Prototyperstellung - Einbeziehung der Endbenutzer: Benutzerzentriertes Design § Entwurfsphilosophie für interaktive Systeme Beispieloberfläche - Leichter Eigenschaften zu nennen, die uns gefallen oder nicht Einfache Prototypen - Papierprotoyp: billig und effektiv | Bildschirme des Systems ODER - Storyboard: Folge von Skizzen (=Abfolge von Interaktionen) Systemprototypen - Throw-Away Protoyp: einmalige Verwendung (z.B. GUI-Mockup, Klickdummy, Prototyping Tools) § Wizard-of-Oz: Person im Hintergrund simuliert Antworten des Systems - Evolutionärer Prototyp: Weiterentwicklung im Projekt (evolutionäre Entwicklung) 103 Software Engineering | RWTH Aachen Beispiel: fachlicher Prototyp (Information, aber optimierbare Darstellung & Auswahl) 104 Software Engineering | RWTH Aachen  Selbststudium! Oberflächenbewertung 1/2 Beurteilung der Benutzerfreundlichkeit & Prüfung der Benutzeranforderungen - Erlernbarkeit § Wie lange dauert es, bis ein neuer Benutzer produktiv mit dem System arbeiten kann? - Antwortgeschwindigkeit § Wie gut passt die Antwortzeit des Systems zur Arbeitsweise des Benutzers? - Stabilität § Wie tolerant ist das System gegenüber fehlerhaften Eingaben? - Wiederherstellbarkeit § Wie gut kann sich das System von Eingabefehlern erholen? - Anpassungsfähigkeit § Wie eng ist das System auf ein einzelnes Arbeitsmodell zugeschnitten? Metriken? - z.B. nach 4h Einschulung können 80% der Systemfunktionalitäten angewandt werden § schwierig zu beurteilen & messen 105 Software Engineering | RWTH Aachen  Selbststudium! Oberflächenbewertung 2/2 Systematische Bewertung - Labore mit Überwachungseinrichtungen - viele Experten (Kognitionswissenschaftler, Grafiker,…) - Statistisch signifikante Anzahl an Experimenten (große Anzahl an typischen Benutzern) - Langwierig & teuer § wirtschaftlich unrealistisch Punktuelle Bewertung - Fragebögen - Beobachtungen - Videoaufnahmen beim typischen Systemgebrauch - Logs & deren Auswertung (Gebrauchsstatistik) § welche Fehler auftreten, welche Hilfsmittel verwendet werden - Feedbackmöglichkeit für Benutzer 106 Software Engineering | RWTH Aachen  Selbststudium! Gedanken zur Überprüfung der Benutzerfreundlichkeit 1/2 Sichtbarkeit des Systemstatus - Genügend Feedback über laufende Funktionen oder den Systemstatus ist stets gegeben Verknüpfung zwischen dem System und der realen Welt - Es ist hilfreich, entsprechende Konzeptmodelle zu erarbeiten, die auf einer Analogie aus der realen Welt basieren. Dadurch ist die Funktionsweise für den Benutzer viel schneller nachvollziehbar oder sogar vorhersehbar. Kontrolle und Freiheit des Benutzers - Der Benutzer sollte immer das Gefühl haben, die Kontrolle auszuüben. Dennoch sollte man dem Benutzer nicht grenzenlose Freiheit einräumen, da er ansonsten überfordert sein und Fehler machen könnte. Konsistenz und Standards - Man sollte immer auf entsprechende interne und externe Konsistenz achten. Darüber hinaus sind, außer in speziellen Ausnahmefällen, immer bestehende Standards zu berücksichtigen. Fehler-Vorbeugung - Potentielle Fehlerquellen sollten frühzeitig eliminiert werden. Der Benutzer muss zudem ausreichend Anleitung erhalten, um keine Fehler zu verursachen. [Nielsen, 1994]: https://www.nngroup.com/articles/ten-usability-heuristics/ 107 Software Engineering | RWTH Aachen  Selbststudium! Gedanken zur Überprüfung der Benutzerfreundlichkeit 2/2 Wiedererkennen vor Überlegen - Bevor der Benutzer nachdenken muss, wie eine Funktion zu bewerkstelligen oder wo sie zu finden ist, sollte er sie direkt anhand des Interfaces wiedererkennen können. Flexibilität und Effizienz der Benutzung - Dies bezieht sich auf die nötige Balance zwischen Abkürzungen (shortcuts) für Experten und ausführlicher Hilfestellung für Anfänger. Ästhetisches und minimalistisches Design - Ein Design sollte stets ästhetisch ansprechend, aber dennoch minimalistisch sein, um unnötige Verwirrung und Übersichtsverlust zu vermeiden. Benutzerhilfe und Support bei Fehlern - Fehlermeldungen müssen klar und verständlich sein. Sie müssen das Problem und eine mögliche Lösung aufzeigen. Hilfe und Dokumentation - Auch wenn es besser ist, ein System ohne Dokumentation betreiben zu können, so ist es manchmal doch nötig, eine Hilfe und eine Dokumentation anzubieten. Diese sollten einfach zu durchsuchen sein und sollten Schritte hin zur Lösung eines Problems aufzeigen. [Nielsen, 1994]: https://www.nngroup.com/articles/ten-usability-heuristics/ 108 Software Engineering | RWTH Aachen Was haben wir gelernt? Entwurfs- Unterstützung für grundsätze Aktivitäten NutzerInnen Passende Analyse der Szenarien Feedbackmöglichkeit Darstellungsart für (Analysephase) Daten & Interaktion Handbücher, Tutorials, auswählen Papier-basierter Erklärvideos und/oder dynamischer Farben: sparsam & Prototyp Interaktive einheitlich Unterstützungs- Bewertung mit systeme: Lernen aus Systemmeldungen: Nutzer:innen & wenn Benutzerverhalten Kontextinformation & notwendig Iteration Rücksicht auf Erfahrungen der Benutzergruppen 109 Software Engineering | RWTH Aachen