Prototyping

8. Prototyping-Werkzeuge
SEW, © Prof. Uwe Aßmann
1
8.1 Arten und Werkzeugklassen
für das Prototyping
SEW, © Prof. Uwe Aßmann
2
Arten von Prototypen
Def.:
Ein Software-Prototyp ist ein leicht herzustellendes, einfach zu änderndes,
ablauffähiges Modell des geplanten Softwareproduktes. Es ist noch unvollkommen, läßt aber vor der eigentlichen Systementwicklung die Erprobung
wesentlicher Eigenschaften durch den Anwender zu. Prototyping nennt
man alle Arbeiten zur Herstellung solcher Prototypen.
vollständige - enthalten alle wesentlichen Funktionen des geplanten
Systems. In Softwaretechnologie ungewöhnlich !
unvollständige - gestatten es, die Brauchbarkeit und Machbarkeit einzelner Aspekte (Benutzungsschnittstelle, Systemarchitektur,
Komponenten) des Systems zu untersuchen.
wiederverwendbare - wesentliche Teile werden bei derImplementierung in das Zielsystem übernommen.
Wegwerfprototypen - dienen für Zwischenphasen als ablauffähiges
Modell und werden bei Implementierung nicht
weiterverwendet.
horizontales - Erfassung der wesentlichen Systemfunktionen und Eigenschaften horizontal über eine komplette Schicht.
vertikales - Ausschnitt aus dem Gesamtsystem ist eine bestimmte
Systemfunktion, die über mehrere Schichten vertikal modelliert wird.
Prof. U. Aßmann, SEW
3
Einteilung des Prototyping
►
a) Exploratives Prototyping:
Erforschung von unbekannten Anwendungen oder Eigenschaften
zur Ermittlung des Informations- und Funktionsbedarfs mit dem Ziel
einer möglichst vollständigen Problemanalyse bzw.
Systemspezifi kation. Prototyprealisierung übernehmen Entwickler
und Anwender gemein- sam. Prototypen sind
Entwicklungshilfsmittel und werden nicht zum fer- tigen Produkt
ausgebaut.
►
►
b) Experimentelles Prototyping:
Experimenteller Nachweis der Tauglichkeit von
Teilspezifi kationen, von Architekturmodellen und
Lösungsmöglichkeiten für Systemkomponenten. Prototyprealisierung
und Experimente werden in der Hauptsache vom Entwickler
durchgeführt.
►
►
c) Evolutionäres Prototyping:
Schrittweise inkrementelle Systementwicklung vom Prototypen mit
klaren Benutzeranforderungen aber unvollständiger
Funktionsanbindung und Qualität zum fertigen Produkt. Die
Systementwicklung verliert den Charakter eines Projektes und wird ein
ständiger die Anwendung beglei- tender Prozess zwischen
Entwickler und Benutzer. Prototypen werden in der Regel nicht
simuliert, sondern ausgeführt.
►
Prof. U. Aßmann, SEW
4
Prototyping-orientiertes Phasenmodell
Problemanalyse
und Grobplanung
Istzustands-Beschreibung, Projektauftrag, Grobplan
Systemspezifi kation, Projektplan, Systemprototyp
Systemspezifi kation
User-InterfacePrototyping
Entwurf
Systemarchitektur, KomponentenStruktur, A.u.K.-Prototypen
Architektur- und
KomponentenPrototyping
Implementierung
Systemimplementierung
Systemtest
fertiges
Produkt
Betrieb und
Wartung
Zeit
Quelle: Pomberger, G., Pree, W.: Grundlagen des Software Engineering; Carl Hanser Verlag
München 2004, S. 30
Prof. U. Aßmann, SEW
5
Prototyping - Zyklus
Reale Welt
analysieren
evaluieren
(ausprobieren)
(Teil-)
Modell bauen
installieren
simulieren
Ideen
Glaube
spez.
testen
progr.
Quelle: nach [4, S. 93]
einrichten
Maschine
Prof. U. Aßmann, SEW
6
Prototyping-Aktivitäten
1. Prototypen konstruieren/spezifi zieren
Daten-, Funktions- bzw. Komponentenauswahl
(horizontal versus vertikal)
2. Prototypen herstellen
3. Mit Prototypen experimentieren
Werkzeuge
4. Prototypen auswerten
Prototyp akzeptiert?
nein
ja
5. Prototypen ändern und erweitern
Prof. U. Aßmann, SEW
7
Prototyp-Evaluationsschritte
Produktbewertung
Produkt
Prüfung auf Standardkonformität
Entwicklungsbegleitende Evaluation
Prototyp
frühzeitiges Feedback
für weitere Dialogschritte
Qualitätssicherung
Gütesiegel (ISO 9000)
Produktauswahl
Quelle: Ziegler,J., Ilg,R.: Benutzergerechte Software- Gestaltung; Oldenbourg Verlag 1993
Prof. U. Aßmann, SEW
8
Durchführbarkeitsstudie
entscheidet über Akzeptanz des Prototypen und damit über Anforderungskonzeption/Systemspezifi kation zwischen Anwender und Systementwickler:
Prüfung der Vollständigkeit der Anforderungen
►alle
funktionalen
und
nichtfunktionalen
Anforderungen(REQUIREMENTS)
bzw.
Nebenbedingungen(CONSTRAINTS) müssen enthalten sein
Prüfung der Konsistenz von Anforderungen
►die Anforderungen dürfen einander nicht widersprechen.
Prüfung der technischen Durchführbarkeit
►das
Zusammenspiel der Software mit der entsprechenden
Hardware muss die gewünschten Leistungen erbringen, dazu gehört
die Bereitstellung der erwarteten Informationen in der geforderten
Menge und Genauigkeit
Prüfung der personellen Voraussetzungen
►für die Projektentwicklung, die Bedienung und den Betrieb des
Software- produktes muss geeignetes Personal zur Verfügung
stehen
Prüfung der Ökonomie
►in einer Kosten-Nutzen-Analyse muss festgestellt werden, ob das
Projekt mit wirtschaftlich vertretbarem Aufwand realisiert werden
kann
Prof. U. Aßmann, SEW
9
8.2 Werkzeuge zur Beschreibung
und Simulation von Dialogen
SEW, © Prof. Uwe Aßmann
10
Anforderungen an Prototyping-Werkzeuge
Allgemeine Anforderungen an Prototyping-Werkzeuge
Gewährleistung einfacher Datenverbindungen mit Analysetools
Einfache Spezifi kation der Benutzungsoberfl äche möglichst grafi sch durch Auswahl
aus Objektbaukästen
Effi ziente Möglichkeit der dynamischen Dialogablaufbeschreibung
Werkzeuggestützte Analyse und Prüfung der Prototyp-Spezifi kation
Inkrementelle Fertigstellung von Prototypen
Erweiterbarkeit/Offenheit des Prototypen zur Verbreiterung (horizontales P.) oder
Vertiefung (vertikales Prototyping) des Problemumfanges
Universelle Nutzbarkeit unabhängig von der konkret vorliegenden Anwendungslösung
Portabilität des erzeugten Prototypen auf mehrere Plattformen
Möglichkeit des weiteren Prototypausbaus zum fertigen Produkt
Automatisierte Dokumentation des Prototypen
Anforderungen an die Benutzung des Prototypen
Schnelle Herstellung, Änderung und Ausführbarkeit(Simulation) von Prototypen
Isomorphes Abbild der Bediensituation für den Benutzer
Prototyp nach Evaluationsmethoden möglichst werkzeuggestützt bewertbar
Prof. U. Aßmann, SEW
11
Aufbau von Prototyping-Systemen
textuell
Editor
semigraphisch
grafi sch
Spezifi kation
generierter
Prototyp
Generator
Oberfl äche
Dialogablauf
Interpreter
Compiler
Code für wiederverwendbaren
Prototypen
Laufzeitsystem/Simulator
Prof. U. Aßmann, SEW
12
Bestandteile und Werkzeuge eines UIMS
Toolkit
Benutzer
User Interface
Manager (UIM)
UIS
UIDS
Dialogdesigne
r
Applikation
Dialogspezifi kationswerkzeuge
Oberfl ächeneditoren
UIMS
UIS = User Interface System
UIDS = User Interface Design System
UIMS = User Interface Management System
Quelle: Götze,R.: Dialogmodellierung für multimediale Benutzerschnittstellen; Diss. Universität Oldenburg 1994
Prof. U. Aßmann, SEW
13
Konstruktionsschritte zum Prototyping
(nach Vorgehen des JANUS-Systems)
Grundlage der Konstruktion eines Prototypen sind Spezifi kationsregeln, nach denen
die Bestandteile des zu modellierenden Systems in
Objekte auf der Oberfl äche transformiert werden (hier am Beispiel des JANUS-Systems):
►
►
►
►
►
- Festlegung der benötigten Fenster und ihre konkreten Arten, z.B. ein
Anwendungsfenster, mehrere Unterfenster, Dialog- und
Mitteilungsfenster
- Bestimmung des konkreten Aufbaus der Fenster und aller benötigten
Bestandteile, wie Titelbalken, Smarticon, Menübar und Pulldownmenüs
einschließlich der Bezeichnungen sowie Felder und weitere Elemente
- Festlegung der Benutzerereignisse, die auf die Oberfl ächenobjekte
reagieren und die gewünschten Zustandswechsel (Fensterübergänge
bzw. Aktivieren anderer Objekte) hervorrufen sollen.
- Umsetzung des Dialogkonzepts mit einem Prototyping-Werkzeug
(UIB oder UIMS) entsprechend den verfügbaren Mitteln, d. h.
Präsentationsbe-schreibung mit grafi schem Editor und/oder
Dialogablaufbeschreibung textuell oder visuell.
- Schrittweise Vervollkommnung des Prototypen durch Anpassung und
Nachkorrektur insbesondere der auf Nachrichten bzw. Ereignisse reagierenden Methoden.
Quelle: Balzert, H.: Lehrbuch Grundlagen der Informatik; Spektrum Akademischer Verlag Heidelberg 1999
Prof. U. Aßmann, SEW
14
Vorgehen des JANUS-Systems
Ansatz:
Aus der objektorientierten Modellierung eines Anwendungsystems (UML)
wird über Transformationsregeln ein Vorschlag für das Objektnetz
der Benutzungsschnittstelle automatisch erzeugt.
Transformationsregeln zur Umsetzung der für die Oberfl äche relevanten Klassen:
Klasse --> Fenster, das sich dann auf alle Klassenmethoden und -attribute bezieht, die
für alle Instanzen von Klasse Gültigkeit besitzen.
Klassenmethoden --> Menüoptionen als eine Möglichkeit der Umsetzung von
Operationen.
Klassenattribute --> Felder im Fenster, die zur Erfassung von Attributwerten der
Klasse benutzt werden können.
Objekte als Instanzen der Klasse --> Einzelfenster abgebildet. Geerbte
Eigenschaften werden nur übernommen, wenn genügend Platz vorhanden ist.
Für Einzelfenster gilt ebenfalls: Objektmethoden --> Menüoptionen und
Objektattribute --> verwendbar als Erfassungsfelder für Attributwerte
Botschaftenverbindungen werden für die Dialogstruktur nicht berücksichtigt.
►
Ziel ist ein dediziertes UI-Metamodell für ein konkretes UIMS.
►
US-System: Automatisierte wissensbasierte Generierung von Mensch-Computer-Schnittstellen; Informatik Forschung und Entwicklu
Prof. U. Aßmann, SEW
15
Integration von JANUS in ObjectiF
Von der Anforderungsanalyse bis zum Klassenmodell unter Nutzung des CASE-Tools
ObjectiF
Einlesen der Daten aus dem Klassenmodell in JANUS
Auf der Basis von Transformationsregeln und (software-ergonomischen) Wissensbasen werden 80-95% der Benutzungsschnittstelle und der späteren Anwendung
generiert
Je nach Variante des JANUS-Generators werden Client-Server-Verteilung, Benutzerund Rechteverwaltung sowie ein Prototyp für das Web-Interface inklusive Servlets
erzeugt.
Erzeugung lauffähiger Programme, nicht nur Code-Gerüste oder -Rümpfe
Bereitstellung vom Methodenrümpfen und spezieller Code-Marken zur Codierung
individueller Anforderungen von Hand
Produkte der JANUS-Generatorfamilie werden als Add-In in ObjectiF integriert
Technische Einbettung des Entwicklungsgenerators JANUS erfolgt über COMSchnittstelle von ObjectiF
Nach dem Start wird das UML-Klassenmodell in jdl-Datei transformiert.
Prof. U. Aßmann, SEW
16
Prototyping-Werkzeug ShortCut*
SA/RT-Modelle des CASE ProMod werden in ihrem dynamischen Verhalten
simuliert und für den Endbenutzer ablauffähig gestaltet.
Konstruktionsschritte:
►
- Gestaltung eines graphischen UI unter Verwendung eines
strukturierten Editors, mit dem nach dem Baukastenprinzip Oberfl ächen
für den kom- merziellen wie technischen Bereich kombiniert werden.
►
- Verknüpfung aller Oberfl ächenelemente mit den Datenfl üssen des
SA/ RT- Modells, die mit Terminatoren verbunden sind, durch
Hinterlegung des Datenfl ußnamens hinter das entsprechende
Oberfl ächenelement.
►
- Festlegung der den elementaren Bestandteilen der Datenfl üsse
zuzuord- nenden Datentypen mittels Auswahl aus einer Dialogbox.
►
- Defi nition von SQL-Datenbankzugriffen zu den Speichern des SAMo- dells, wenn relationale Datenbanken (Ingres, Oracle, Sybase) für
das Proto- typing genutzt werden sollen.
►
- Beschreibung der (Dialog-)Ablaufl ogik durch interpretierbaren
Pseudo- code oder realen Programmcode hinterlegt den SA/RTProzessen bzw. als Ergänzung/Umsetzung der Minispecs.
* ShortCut ist ein Produkt der Firma CSE Salzburg.
Prof. U. Aßmann, SEW
17
JBuilder Foundation
Hersteller:
•
•
Borland Corporation in Scotts Valley, Kalifornien
(Im November 2006 wurden die Entwicklungswerkzeuge, darunter auch JBuilder, von
Borland in eine neue Tochtergesellschaft Namens CodeGear ausgegliedert.)
Plattform:
Windows, Linux, Solaris, Apple Mac OS X
Zielsprache: Java
Charakteristik:
–großer Hauptspeicherbedarf
–visueller Designer
–Verwendung von Wizards
–Benutzung von Swing Controls
–farbliche Syntaxunterstützung (frei definierbar)
–Verwendung Java Beans mit dem Entity Bean Modeller
–integrierter Debugger
–Web-Entwicklung mit Internet Bean Express/Struts (Open Source Framework)
–UML Code Visualisierung
–mehrere Projekte können gleichzeitig bearbeitet werden
Verfügbarkeit: freies Download JBuilder 2005 Foundation
URL: http://www.codegear.com/Downloads/TrialandFreeVersions/JBuilder/tabid/143/Default.aspx
Prof. U. Aßmann, SEW
18
Jigloo GUI Builder for Eclipse
Hersteller:
Cloud Garden
Plattform:
Linux, Apple Mac OS X, Windows
Zielsprache: Java
Charakteristik:
–Plugin für die Eclipse Java IDE und WebSphere Studio
–Entwicklung von Swing- und SWT-Komponenten
–Erstellung der GUI nach dem WYSIWYG-Prinzip
–Leichte Handhabung von Objekten
–Einfach zu bedienende Oberfläche
–Komponentenauswahl aus Paletten
–Nutzung aller Funktionen von Eclipse möglich

Prof. U. Aßmann, SEW
19
Eclipse Visual Editor Project (VEP)
The Eclipse Project
Hersteller:
Windows, Linux, Mac OS
Plattform:
Zielsprache: Java
Charakteristik:
−Plugin für Eclipse SDK
−Entwicklung von Swing- und SWT-Komponenten
−Erstellung der GUI nach dem WYSIWYG-Prinzip
−Vergleichbar mit Jigloo
−Wurde als Framework entwickelt
−Nutzung aller Funktionen von Eclipse
Verfügbarkeit: freier Download, Open Source,
URL: http://www.eclipse.org/vep/WebContent/main.php
►
►
Prof. U. Aßmann, SEW
20
Simulationstool in teamwork
Es erlaubt dem Nutzer, ein SA/RT-Modell auszuführen, um daraus Rückschlüsse
auf das Verhalten seiner Komponenten und seiner Leistungsfähigkeit zu ziehen.
Durchgeführt wird eine symbolische Simulation auf der Basis von Token, indem
für ein vorzugebendes Input-Szenario von Ereignissen und Eingaben das Modellverhalten über die Zeit simuliert wird.
Für die Simulation sind darüber hinaus zu spezifi zieren: (Defaultwerte vorh.)
 Simulationsattribute der Modellkomponenten
►• Prozessattribute, wie z.B. Datenaufnahme,
Schaltdauer,...
►• Datenf
l ussattribute, wie z.B.
Erzeugungswahrscheinlichkeit,..
► unterschieden nach den
Verbindungskomponenten
►• Speicherattribute, wie z.B. Zugriffsdauer
►• Signalf
l ussattribute, speziell
Erzeugungswahrscheinlichkeit
►• Hardwareattribute, z.B. relative
Verarbeitungsgeschwindigkeit
 Wurzeldiagramm mit Modelltiefe (DFD-Simulationsausschnitt)
Modellsicht, d.h.
implementationsunabhängig
oderDFD-Editors
mit
•
Durchführung:
 essentiell
Dialogmodus:
Menüpunkt 'Simulation' des
Berücksichtigung
der Hardwaremodule
 Stapelmodus: Vorbereitung
eines Kommandof
i les nötig
►
Ergebnisse: Trace Files, Simulations-Statistiken,Fehlerprotokoll
Prof. U. Aßmann, SEW
21
Vorteile des Prototyping
Die Anforderungen und Analyseergebnisse sind aufgrund der Beteiligung
von Nicht-DV-Spezialisten besser fundiert.
Durch schnelle Verfügbarkeit und frühzeitige Erprobung werden Entwurfsfehler vermieden.
Als Folge der unmittelbaren Beteiligung der Anwender erhöht sich die
Akzeptanz des späteren Softwareproduktes.
Frühzeitige Experimente mit Prototypen der Benutzungsschnittstelle führen
zu ergonomisch günstig gestalteten Produkten.
Die frühzeitige Auseinandersetzung mit dem Prototypen führt zu einer
vorgezogenen Einsatzvorbereitung, während der die Benutzer geschult
und trainiert werden.
Im umgekehrten Fall ergeben sich bei den Entwicklern beschleunigte
Lernprozesse über das Anwendungssystem.
Größere Sicherheit von Anforderungsanalyse und Entwurf ist Basis für eine
bessere Planbarkeit, Aufwandsabschätzung und Termintreue.
Frühzeitige Fehlererkennung senkt Betriebs- und Wartungskosten.
Qualitätsmerkmale Benutzerfreundlichkeit, funktionale Adäquatheit, Änderund Erweiterbarkeit, Korrektheit und Zuverlässigkeit werden gesteigert.
Prof. U. Aßmann, SEW
22
Schwierigkeiten beim Prototyping
Prototyp-Ergebnisse dürfen nicht zu spät kommen, damit sie die
Entwicklung im gewünschten Maße beeinfl ussen können.
Prototypen können schwer eingrenzbar und groß werden, womit sie später
verfügbar und ihrer Funktion nicht voll gerecht werden.
Die Prototyp-Entwicklung ist ein zusätzlicher Aufwand, der in der Regel die
Kosten erhöht und die Entwicklungszeit verlängert.
Die Prototyp-Entwicklung zieht mitunter die Aufmerksamkeit mehr von der
Produkt-Entwicklung ab als vertretbar ist.
Prototypen erwecken den Anschein, die meisten Probleme gelöst zu haben.
Das kann zu gefährlichen Fehleinschätzungen (beim höheren Management)
führen.
Wenn Prototypen nur in geringem Maße weiterverwendet werden, können
sie als bloße Wegwerf-Software zu teuer werden.
Prototyp kann zum dauerhaften Provisorium werden und die methodengestützte Entwicklung des eigentlichen Produktes verhindern.
Unterschied zwischen Prototyp und eigentlichem Produkt verschwindet, was
zum Rückfall in das "code and fi x", anstatt zu einer systematischen,
wohlgeplanten top-down Systementwicklung führen kann.
Prof. U. Aßmann, SEW
23