|
|
 |
Informatik-Lexikon
E
e-Business
Elektronisches Papier
Entwurfsmuster
Expertensystemshell-Baukasten
Extremes Programmieren (XP)
e-Business
Kurzinfo Nicht
jede Form der Kommunikation zwischen Kunden und Geschäften oder von Unternehmen
mit ihren Lieferanten ist e-Business, sowenig wie alle Gesundheitsversprechungen
von Tinkturen, Säften, Bädern und Salben medizinisch wirklich helfen.
|
Erläuterung
Unverstandene Zusammenhänge werden hier wie dort auf die Seite geschoben
und nur die Chancen einer Erstplatzierung in einem innovativen Geschäftsfeld
gesehen. Hier soll folgende Anforderung als Messlatte dienen: Integrierte
Ausführung aller digitalisierbaren Bestandteile ökonomischer
Prozesse.
Diese knappe, aber gleichzeitig sehr weit reichende Formulierung bedarf
einer detaillierten Erläuterung, da nur so der extreme Anspruch der
eigentlichen e-Business-Idee mit allen Konsequenzen deutlich wird.
-
Integrierte Ausführung" ist hier die Umschreibung
für eine medienbruchfreie, rechnerbasierte und damit nach Möglichkeit
automatisierte Reaktion auf eingehende Informationen sowie die Ausgabe
von auf anderen Rechnern weiterbearbeitbaren Ergebnissen und nur so
weit unumgänglich für handelnde Personen.
-
Digitalisierbare Bestandteile" sind alle Aufgaben der
Informationsverarbeitung in Geschäftsprozessen. Sie reichen von
der Beantwortung von Kundenanfragen über die Beschreibung des
betrieblichen Leistungsumfangs, die Vorlage eines konkreten Angebots,
die Bestellung, deren Bestätigung, die Auftragsverfolgung, eine
Lieferbescheinigung, die Rechnungsstellung und die Zahlungsabwicklung
bis zu damit verbundenen Benachrichtigungen von Logistikdienstleistern
und der öffentlichen Hand (Steuer, Zoll), zur Bearbeitung von
Reklamationen inklusive Servicefällen und schließlich zu
Hinweisen auf Produktweiterentwicklungen sowie neuen Offerten für
den entstandenen Kundenstamm. Teilweise können sogar die Lieferungen
und Leistungen selbst digitalisierbar sein, wie beim Vertrieb von
Zeichnungen, Texten, Programmen. Künftig werden digitale Produkte
auch erst beim Käufer in eine physische Form gebracht (z.B. CD-Brennen,
3D-Formausgabe).
-
Ökonomische Prozesse" sind alle Anstrengungen, bei
denen Wirtschaftssubjekte Güter im Ausgleich für Gegenleistungen
abgeben. Das Auffinden des passenden Partners ist häufig der
aufwendigste Teil eines Geschäftsprozesses. Gerade diese Suche
kann jedoch über digitale Informationsströme erheblich verbessert
und erleichtert werden.
i- statt e-Business
Aus dieser umfangreichen und inhaltlich anspruchsvollen Beschreibung
der zum e-Business gehörenden Funktionen wird zweierlei deutlich.
Zum einen, dass mit dem Attribut elektronisch "nicht wirklich
eine pointierte Abgrenzung erreicht wird. Andere Termini hätten den
angestrebten Charakter der neuen Form der Geschäftsprozessabwicklung
treffender dargestellt. Mit dem Wort digital "hätte man
zumindest die Art der Informationsdarstellung beschrieben; mit organized
"die planerische Struktur der Weiterverarbeitung benannt und mit
dem treffendsten Wort integrated "gar darauf hingewiesen, dass
Electronic Business nur Sinn macht, wenn es die Basis für eine durchgängige
Verbindung zwischen den Geschäftsprozessbeteiligten legt. Zum anderen
stellt die obige Auflistung von Anforderungen klar, dass in den meisten
Praxisfällen von e-Business heute erst Ausschnitte aus dem jeweils
sinnvoll möglichen Aufgabenfeld realisiert sind.
Die Schritte zu einer wirklich koordinierten Abwicklung von Geschäftsprozessen
sind noch weit, komplex und aufwendig. Der verbreitete, großzügige
und unspezifische Umgang mit dem Begriff bezieht jedoch fast jede Form
von elektronischer Geschäftskommunikation ein und hat, wie nicht
anders zu erwarten, zu deutlicher Verunsicherung und Enttäuschung
beigetragen. Damit ist auch die entstandene Zurückhaltung bezüglich
weiterer Projekteerklären. Hätten die Beteiligten von vornherein
gewusst, dass das Einsparungspotential nicht in der Anwendung von e-Business-Lösungen
liegt, sondern nur in den dadurch möglich werdenden neuen organisatorischen
Abläufen, dann wäre von vornherein mehr Gewicht auf die Umstrukturierung
der eigenen Organisation gelegt worden.
Es bestehen aber auch formelle Abgrenzungsprobleme für den e-Business-Begriff,
insbesondere zu seiner Vorgängerversion in Form von e-Commerce. Dieser
im amerikanischen Sprachraum ab etwa 1995 verbreitete Ausdruck wurde erst
durch die drei Jahre später gestartete massive Werbekampagne der
IBM für Electronic Business abgelöst.
Einzelne Versuche, den beiden Begriffen jeweils individuelle Aufgabenfelder
zuzuordnen, waren nicht erfolgreich; danach wäre e-Commerce die Bezeichnung
für den mit B to C (Kurzform b2c, Langform Business to Customer)
beschriebenen Handel mit Konsumenten und e-Business für die durch
B to B (Kurzform b2b, Langform Business to Business) gekennzeichnete zwischenbetriebliche
Geschäftsabwicklung.
Der griffigere Ausdruck e-Business hat jedoch alle genannten Varianten
in sein Spektrum einbezogen und umfasst heute sogar auch noch die Anbindung
der öffentlichen Verwaltung in Form von G to C (Kurzform g2c, Langform
Government to Citizen).
Transaktionskosten
Die zu großen e-Business-Erwartungen der durch den so noch nie
da gewesenen, konzertierten Werbeauftritt der großen IT-Anbieter
und Medien angesprochenen Unternehmen und Privatpersonen, die nicht nur
auf ihre eigenen betrieblichen Anwendungsmöglichkeiten, sondern oft
genug auch auf die Gewinn bringende Geldanlage gerichtet waren, mussten
zwangsläufig enttäuscht werden. Die maßlosen Wertsteigerungsprognosen
für e-Business-Unternehmen sollen hier nicht kommentiert werden.
Sie haben jedoch einer breiten Öffentlichkeit suggeriert, dass mit
e-Business fast jedes Unternehmen Wettbewerbsvorteile erzielen kann.
Um so schwieriger bleibt die Weiterentwicklung von, wie mittlerweile
jeder zu wissen glaubt, nicht erfolgreichen Projekten. Die Simplifizierung
der Entwicklungsschritte, die durch e-Business zu einer Kostenersparnis
führen können, war aber von den Lösungsanbietern bewusst
hingenommen oder sogar angestrebt worden.
Der Auslöser und Grund für die positive Einschätzung
einer friktionslosen und damit auch fast kostenlosen Kommunikation unter
den Wirtschaftssubjekten sind die außerordentlich hohen sog. Transaktionskosten,
die jedes Geschäftsgeschehen begleiten. In Zeiten des Realgütertausches
mussten die Wirtschaftssubjekte passende Tauschpartner finden, die nicht
nur das jeweils gewünschte Objekt herzugeben bereit waren, sondern
auch noch am selbst angebotenen Gegenstand Interesse hatten ein
mühseliges Unterfangen. Die Erfindung des Geldes hat diesen Aufwand
drastisch reduziert, weil damit ein in beliebige Stückelung zerlegbarer
Zwischenwertträger gegeben war. Aber schon damals hat nicht jeder
Münzenpräger eine hervorragende Geschäftsentwicklung gehabt;
Voraussetzung war die Sicherstellung einer durchgängigen Tauschkette
für die ausgegebenen Münzen und Noten.
Alle Fortschritte wurden jedoch vom Erfindungsreichtum bürokratischer
Gehirne und Hoheitsträger zunichte gemacht, die in Form von Zöllen
und Steuern an den Geschäften partizipieren wollen und diesen Anspruch
mit einer Unzahl von Belegen, Begleitpapieren, Formularen und sonstigen
für den eigentlichen Geschäftsablauf völlig irrelevanten
Unterlagen durchsetzen. Die Schätzungen für die Höhe solcher
oktroyierter und auch von den Geschäftspartnern selbst verursachter
Transaktionskosten liegt bei 50%unseres Bruttosozialproduktes. Das ist
des Pudels Kern! Die Vermeidung solcher von keinem Tauschpartner gewollter
Kosten könnte wegen der damit einhergehenden Verbilligung der Waren
zu einem höheren Umsatz, höheren Gewinn und nicht zuletzt zu
einem höheren Wohlstand führen.
Die offenkundige Reduktion der bloßen Übertragungskosten
bringt jedoch kaum Einsparungen. Eine im Jahr 1996 veröffentlichte
Studie von Booz, Allen und Hamilton sah den Transaktionskostenunterschied
zwischen einem in der Bankfiliale abgegebenen Überweisungsträger
(1,07 DM) und einer über e-Banking ausgelösten Zahlung (0,01
DM) immerhin bei einem Faktor 1:100. Bereits damals wurde die Aufstellung
falsch interpretiert, denn die Einsparungen entstehen nicht durch die
Vermeidung des Papierbeleges an sich oder die Nutzung des elektronischen
Kanals. Kostenvorteile entstehen erst durch die medienbruchfreie, rechnerbasierte
und damit weitgehend automatisierte Bearbeitung der Geschäftsprozesse.
Die kann aber nur durch organisatorische Anpassung und die über mehrere
Beteiligte hinweg erreichte Vereinheitlichung der Datenstrukturen realisiert
werden.
Es ist ein unliebsames Phänomen, aber e-Business als Basis einer
neuen zwischenbetrieblichen Geschäftsprozessabwicklung muss mit organisatorischen
Bemühungen innerhalb der zu beteiligenden Unternehmen beginnen und
bringt Kosteneffekte erst nach der überbetrieblichen Zusammenarbeit.
Diese wurde zwar durch die Verbreitung des Internet als technische Basis
der Datenkommunikation erheblich erleichtert, genügt so aber nicht
für die Weiterverarbeitung der ausgetauschten Daten.
Semantische Geschäftsprozessintegration
Diese inhaltsorientierte Verbindung von Geschäftspartnern setzt
eine einheitliche Beschreibung der auszutauschenden Informationen voraus;
eine solche ist aber noch nicht wirklich in Sicht. Viele Anstrengungen
wurden unternommen. Über die Protokolle des ISO-7-Schichten-Modells
hinaus wurden als qua-si 8. Schicht zunächst bilaterale Vereinbarungen
über die formale und inhaltsbezogene Darstellung der Daten aufgestellt.
Die Versuche von Industrieorganisationen, wie dem Verband der deutschen
Automobilhersteller (VDA), verliefen wenig erfolgreich, weil die beteiligten
Anwender auf das einheitliche "Verbandsprotokoll noch individuelle
Ergänzungen aufsetzten. Ähnlich schwierig stellt sich der Vorschlag
der Vereinten Nationen in Form des Electronic Data Interchange for Administration
Commerce and Transport (EDIFACT)dar, der durch die Detaillierung in so
genannte Subsets kaum mehr eine einheitliche Basis für den Informationsaustausch
bietet.
Der jüngste Hoffnungsträger für die Sisyphos-Aufgabe,
zwischen allen Beteiligten an Geschäftsprozessen inhaltlich richtig
interpretierbare Botschaften auszutauschen, wird in Form von XML propagiert.
Zwar ist dieser Ansatz gerade auch für die e-Business-Welt mit ihrer
Einbeziehung der Endkunden (CRM, Customer Relationship Management) die
bisher beste Lösung, aber sie ist weiterhin noch deutlich entfernt
von de einheitlichen Beschreibungsziel. Der XML inhärente Vorteil,
neben der inhaltlichen auch eine formale Beschreibung (mit XSL) mitzuliefern,
kann zwar hervorragend für die Gestaltung von Seiten benutzt werden,
die menschliche Kunden ansehen, für die Transaktionskosteneinsparung
nutzt dies aber wenig. Der zweite Vorteil von XML, spezielle Tags zu definieren,
hilft wiederum nur den Geschäftspartnern, die sich über diese
Bezeichner abgestimmt haben (SCM, Supply Chain Management und SRM, Supplier
Relationship Management).
Leider sind zz. mehrere Standards" in Entwicklung, wie eXML,
xCBL und ebXML, deren Existenz eine verlässliche Interpretation empfangener
Datensätze durch einen beliebigen Adressaten zweifelhaft macht. Schon
bei der geringsten Abweichung vom vordefinierten Sprachgebrauch versagt
der Ansatz kläglich. Auch ein menschlicher Empfänger kann eine
mitgeschickte sog. Document Type Definition nicht eindeutig auslegen,
u so weniger ein Automat.
Was bleibt? Genauso falsch wie die zuvor übersteigerte Hoffnung
auf e-Business-Anwendungen ist jetzt die Abkehr von entsprechenden Projekten,
die nicht schnell genug zu Resultaten führten und im Sog des allgemeinen
wirtschaftlichen Abschwungs gestrichen oder doch zumindest verschoben
werden. Geschäftsprozessvereinfachungen und damit massive, den Rationalisierungsbemühungen
in der Produktion der vergangenen 100 Jahre entsprechende Kosteneinsparungen
sind nur mit einem anspruchsvollen e-Business bzw. einer medienbruchfreien,
rechnerbasierten und damit weitgehend automatisierten Bearbeitung der
Geschäftsprozesse möglich; es gibt keine Alternative.
Die wirkliche Innovation von Henry Ford war auch nicht das Fließband
(Internet),sondern die Standardisierung der Bauteile (Semantik).
Um e-Rationalisierungs-Effekte zu erreichen, gilt es daher einerseits,
verstärkt an der Vereinheitlichung der inhaltlichen Beschreibung
von Geschäftsprozessinformationen zu arbeiten, und andererseits,
vom Oberflächendenken des e-Business-Hypes zu den organisatorischen
Auslösern von Transaktionskosten vorzudringen. Nur die integrierte
Ausführung aller digitalisierbaren Bestandteile ökonomischer
Prozesse "bietet der Menschheit die Chance, Transaktionsprozesse
zu rationalisieren und damit Wohlstandsverbesserungen zu ermöglichen.
Artikelanfang Seitenanfang |
|
Literatur
- Hermanns, A., Sauter, M. (Hrsg.): Electronic Commerce. 2. Aufl. München:Vahlen
2001
- Thome, R., Schinzer, H. (Hrsg.): Electronic Commerce. Anwendungsbereiche
und Potentiale der digitalen Geschäftsabwicklung. 2. Auflage. München:Vahlen
2000
Artikelanfang Seitenanfang |
|
Autor & Copyright
Prof. Dr. Rainer Thome
Lehrstuhl für BWL und Wirtschaftsinformatik,
Universität Würzburg.
© 2002 Informatik Spektrum, Springer-Verlag Berlin Heidelberg
Artikelanfang Seitenanfang |
Elektronisches Papier
|
Kurzinfo „Immer
leichter, immer schmaler, immer preisgünstiger" lautet die Devise in der
aktuellen Displayforschung. Neue Technologien aus diesem Bereich können
sich darüber hinaus zusätzlich durch vielfältige Einsatzmöglichkeiten
auszeichnen.
|
Erläuterung
Die Ursprünge der Entwicklung des elektronischen Papiers liegen
in der Displayforschung. Hier entstand bereits in den 1970er Jahren die
Idee des elektronischen Papiers, denn die damaligen Displays zeichneten
sich nicht durch ergonomische Vorteile oder gar gute Lesbarkeit aus. Der
Gedanke, ein elektronisches Papier zu nutzen, hatte also besonderen Charme.
Insbesondere die erfolgreiche Übertragung der typischen Charakteristika
von traditionellem Papier hohe Kontrastwerte, Unabhängigkeit
vom Lichteinfallwinkel, Lesbarkeit auch bei ungünstigen Blickwinkeln
sowie geringer Stromverbrauch lassen das elektronische Papier als
Bindeglied zwischen der Welt der elektronischen Informationen und der,
in der zu Lesendes klassisch auf Papier gedruckt wird, erscheinen.
Elektronische Tinte
Nicholas K. Sheridon, seinerzeit noch Mitarbeiter im Xerox Palo Alto
Research Center (PARC), gründete zur weiteren Erforschung der Grundidee
1998 die Firma Gyricon Media als Spinoff von Xerox [1].Neben
Gyricon Media forscht E Ink als Spinoff des Massachusetts Institute of
Technology (MIT)an einer vergleichbaren Technologie [2,
S.47].
Ergebnis dieser Forschungstätigkeiten sind zwei unterschiedliche
Ausprägungen der elektronischen Tinte, auf der letztlich das elektronische
Papier basiert. Abbildung 1 bietet eine Gegenüberstellung der verschiedenen
Technologien.
|
Abb. 1 Funktionsweise der elektronischen Tinte der Unternehmen Gyricon media und E Ink [4]
|
Die E-Ink-Technologie verwendet zur Darstellung eines Bildpunkts eine
etwa haardünne Mikrokapsel. In diesen Kapseln sind positiv oder negativ
geladene Partikel in einer öligen Flüssigkeit eingelagert. Zwischen
zwei transparenten Kunststoffelektroden in Form eines Folienfilms wird
eine große Anzahl dieser Mikrokapseln angeordnet. Die Anordnung
der Kapseln ermöglicht eine Ansteuerung einzelner Bildpunkte über
die Elektroden. Wird über die innere Elektrode ein elektrisch positives
Feld angelegt, bewegen sich die weißen Partikel in Richtung Oberfläche
der Mikrokapsel. Gleichzeitig wird über die äußere, transparente
Elektrode ein negatives Feld angelegt, was die schwarzen Partikel nach
innen bewegt und sie damit nichtsichtbar macht. Analog wird ein schwarzer
Bildpunkt erzeugt [5].
Im Unterschied zu E Ink verwendet die Gyricon-Technologie zweifarbige
Kügelchen, die einen elektrischen Dipol aufweisen. Die Kügelchen
werden in einer dünnen, transparenten und flexiblen Kunststofffolie
in Aushöhlungen gelagert, wo sie sich in einer Flüssigkeit drehen
können. Analog zum elektronischen Papier von E Ink wird über
Elektroden die farbige Ausrichtung der Partikel erzielt [6].
Im März 2003 präsentierte Siemens eine eigene Initiative zur
Entwicklung eines elektronischen Papiers, basierend auf dem Einsatz elektrochromer
Moleküle. Diese verändern ihre Färbung, wenn eine elektrische
Spannung angelegt wird. Der Kern dieser Displays besteht ebenfalls aus
einer Folie, in die Elektroden eingeprägt sind. Über eine Steuerungselektronik
werden abwechselnd bestimmte Teile durch Anlegen einer elektrischen Spannung
aktiviert, um Bilder und Zeichen sichtbar zu machen [9].
Allen drei Ansätzen gemein ist die Nutzung der bistabilen Eigenschaft
der benutzten Farbpigmente, d.h., eine Spannung muss lediglich zur Änderung
eines Bildes angelegt werden. Anschließend hält das Material
diesen Zustand bei, sodass ohne weiteren Stromverbrauch das einmal erzeugte
Bild weiter angezeigt wird. Das anzuzeigende Bild kann mittels geeigneter
Treiber sowie einem an das elektronische Papier angepassten Controller
zur Darstellung gelangen. So können z.B. pdf-Dateien oder Bilddateien
auf elektronischem Papier dargestellt werden.
Materialcharakteristika des elektronischen Papiers
Das elektronische Papier basiert auf diesen grundlegenden Technologien.
Den drei Ansätzen gemein sind die Vorteile, die sie für den
Einsatz als Display und insbesondere als elektronisches Papier geeignet
erscheinen lassen [8, S.570]:
- Als Trägermaterialien der elektronischen Tinte kommen viele Materialien
in Frage, z.B. Kunststoff, Metall usw. Dies gewährleistet eine
hohe Anwendungsbreite, wobei sich Kunststoffe als Trägermaterial
beim elektronischen Papier durchzusetzen scheinen. Dafür spricht
die hohe Robustheit und Flexibilität der gewählten Kunststoffe.
- Insbesondere im Vergleich zu Alternativtechnologien aus dem Bereich
der Displayforschung (z.B. OLED, TFT, LCD) bestehen produktionstechnische
Vorteile und gelangen kostengünstigere Materialien zum Einsatz.
- Das Gewicht der Kunststoffe, die als Trägermaterial dienen,
ist relativ niedrig.
- Der Stromverbrauch ist aufgrund der bistabilen Eigenschaft
der elektronischen Tinte sehr gering. Lediglich um eine Bildänderung
herbeizuführen, muss eine Spannung angelegt werden. Dies führt
dazu, dass für den Einsatz in mobilen Endgeräten kleine und
leichte Stromversorgungseinheiten verwendet werden können.
- Die Lesbarkeit des Displays (Reflexion, Kontrast, möglicher
Betrachtungswinkel) ist teilweise erheblich besser als bei vergleichbaren
Displaytechnologien.
Abhängig von der gewählten Einsatzart des elektronischen Papiers
spielen die verschiedenen Vorteile eine unterschiedlich starke Rolle.
Diese Materialcharakteristika ermöglichen gleichzeitig eine Abgrenzung
zu anderen Displaytechnologien.
Zu nennen sind hier insbesondere organische Leuchtdioden (OLEDs),die
zwar ebenfalls durch eine geringe Dicke, niedriges Gewicht sowie niedrigen
Stromverbrauch gekennzeichnet, aber nur eingeschränkt flexibel und
zudem sehr empfindlich sind. Außerdem sind bistabile LCD-Displays
zu nennen, die jedoch den Nachteil der schlechteren Lesbarkeit haben,
da diese abhängig von Betrachtungswinkel und Lichteinfallwinkel ist.
Als ergonomisches Charakteristikum bleibt noch die Rollbarkeit
des Materials zu nennen. Wenngleich physische Hindernisse derzeit eine
Faltbarkeit des elektronischen Papiers unmöglich machen, so kann
das Material derzeit bereits auf einen Durchmesser von 1,5 cm gerollt
werden [5].
Weiterentwicklungen
Unabhängig von den genannten Vorteilen ist zu erwarten, dass die
Materialforschung zukünftig höher auflösende, leichtere
und dünnere Displays, die auf elektronischer Tinte basieren, hervorbringen
wird. So ist E Ink eine Kooperation mit Toppan, einem Unternehmen aus
der Druckbranche, eingegangen, um die Forschungen an farbigem elektronischen
Papier weiter voran zu treiben. Mit Philips wurde eine Kooperation bei
der Entwicklung des elektronischen Papiers für PDAs gestartet. Nach
den anfänglichen, niedrig auflösenden Displays wird der Schritt
über die Erhöhung der Auflösung bis hin zu farbigen und
flexiblen Displays vollzogen.
Die Haltbarkeit des Materials wird derzeit von den entwickelnden Unternehmen
mit 5 Millionen Bildwechseln [6] bzw. 30.000
Einsatzstunden [5] angegeben.
Anwendungsgebiete Siemens präsentierte als Anwendung seines elektronischen
Papiers ein 10 ×10 cm großes, in einem Stift eingerolltes
Display für die Oberfläche eines PDA. Eine ca. DIN-A4-große
Folie diente zur Darstellung einer Zeitungsseite und einer Anzeigenseite
[9].
Der Ansatz der beiden amerikanischen Unternehmen E Ink und Gyricon Media
stammt aus dem Bereich der Werbetafeln in Kaufhäusern. Hier bietet
elektronisches Papier eine kostengünstige Alternative zum Druck von
Papierwerbetafeln. Daneben setzt die Vossloh System-Technik GmbH Anzeigetafeln,
die auf elektronischer Tinte basieren, ein.
Displays, die auf elektronischem Papier basieren, können substituierend
als Ersatz für andere Displaytechnologien oder in ganz
neuen Anwendungsgebieten eingesetzt werden. Substituierenden Charakter
haben sie sowohl beim Einsatz in Handys, PDAs, bei Anzeigetafeln oder
E-Books als auch in Autoradios, GPS-Systemen und vielen anderen elektronischen
Geräten. Die Einführung eines mit elektronischer Tinte von E
Ink ausgestatteten E-Books in Japan steht kurz bevor.
Mit dem elektronischen Papier eröffnen sich daneben völlig
neue Anwendungsszenarien. Denkbar ist beispielsweise der Einsatz in Werbetafeln,
Regalstoppern, bei der Preisauszeichnung in Supermärkten oder bei
textilen Displays (z.B. die Armbanduhr auf dem Hemdärmel).Daneben
eignet es sich als elektronisches Whiteboard, für den Automotive-Sektor
(z.B. Anzeigen in Automobilen)und als Material für (hochwertige)Verpackungen.
Ein gänzlich neues Anwendungsfeld entsteht durch den Einsatz des
elektronischen Papiers als elektronische Zeitung. Die Flexibilität
des Materials, verbunden mit niedrigem Gewicht und geringem Stromverbrauch,
ermöglicht es, ein neues mobiles Endgerät die elektronische
Zeitung zu entwickeln. Verbunden mit den Möglichkeiten der
aktuellen Funktechnologien wie beispielsweise UMTS oder WLAN bietet sich
den Zeitungslesern eine neue mediale Welt, die auch unterwegs nutzbar
ist. Der innovative Charakter einer elektronischen Zeitung spiegelt sich
vor allem in der Konvergenz von ergonomisch gewohnt handhabbarer Zeitung
und der Integration in die Welt der digitalen Medien wieder.
Eine Abgrenzung zur heute schon bekannten, jedoch nur wenig erfolgreichen
Internetzeitung zeigt eine Designstudie von IBM aus dem Jahr 1999 (Abb.2).
|
Abb. 2 Designstudien zur elektronischen Zeitung 1999 und 2000 [ 3, 7]
|
Auch wenn hier noch nicht das elektronische Papier verwendet wurde (damals
wurde lediglich eine Papierzeitung in einen Rahmen gespannt), so zeigen
sich auf dem Bild doch zwei wesentliche Charakteristika einer Zeitung:
Sie lebt vom Ambiente, also beispielsweise dem ortsunabhängigen Lesen
(vielleicht auch mit einer Tasse Kaffee), und vom Gefühl, ein papierähnliches
Medium in Händen zu halten.
Vielleicht steht daher mit Marktreife des (flexiblen und farbigen)elektronischen
Papiers ein Anwärter für eine Anwendung in UMTS-Netzen in den
Startblöcken. Angekündigt ist die Marktreife des Materials für
das Jahr 2004/2005.Dann lassen sich auch die weiteren Potenziale der elektronischen
Zeitung nutzen: Dazu zählen insbesondere die laufende Aktualisierbarkeit
sowie die Personalisierbarkeit der Inhalte, Werbung und Anzeigen.
Artikelanfang Seitenanfang
|
|
Literatur
- Battey, J.: Electronic paper gets its bearing.
http://staging.infoworld.com/articles/hn/xml/
01/04/16/010416hnetrend.xml ?Template=/storypages/ printfriendly.html
(Abruf am 08.09.2002)
- Deussen, N.: Das Buch der Zukunft. In: Mobil
11, 4647 (2001)
- Dienna, S./IBM: Electronic newspapers. Interactive
Services 2000 Conference (2000), Konferenzvortrag.
- Ditlea, S.: The electronic paper chase.
http://www.sciam.com/article.cfm
?articleID=0004C2D2-B9381CD6B4A8809EC588EEDF
&pageNumber=1&catID=2 (Abruf am 31.03.2003)
- E Ink: Technology.
http://www.eink.com/technology/index.html
(Abruf am 31.03.2003)
- Gyricon Media: SmartPaper FAQ.
http://www.gyriconmedia.com/smartpaper/faq.asp
(Abruf am 31.03.2003)
- IDSA (Industrial Designers Society of America):
IBM electronic newspaper.
http://www.idsa.org/whatis/seewhat/idea99/winners/epaper.htm
(Abruf am 31.03.2003)
- Schryen, G., Karla, J.: Elektronisches Papier
- Displaytechnologie mit weitem Anwendungsspektrum. In: Wirtschaftsinformatik
6, 567574 (2002)
- Siemens: Siemens Innovationen paperlike display.
http://www.siemens.com/
index.jsp?sdc_rh=null&sdc_flags=null&sdc_sectionid=0&sdc_secnavid=
0&sdc_3dnvlstid=&sdc_countryid=0&sdc_mpid=0&sdc_unitid=999&sdc_
conttype=2&sdc_contentid=1060936&sdc_langid=0& (Abruf
am 31.03.2003)
Hinweis: Die URLs entsprechen dem Stand bei der Veröffentlichung
des Artikels und werden nicht aktualisiert.
Artikelanfang Seitenanfang
|
|
Autor & Copyright
Dipl.-Kfm. J. Karla
Lehrstuhl für Wirtschaftsinformatik und Operations Research,
RWTH Aachen,
Templergraben 64,
52056 Aachen E-Mail: karla@winfor.rwth-aachen.de
karla@winfor.rwth-aachen.de
DOI 10.1007/s00287-003-0333-1
© 2003 Informatik Spektrum, Springer-Verlag Berlin Heidelberg
Artikelanfang Seitenanfang
|
Erläuterung
Der Architekt Christopher Alexander hält die Keynote-Ansprache
auf der OOPSLA 96 der bedeutendsten Konferenz über die
objektorientierte Softwaretechnik. Sein Musterbegriff, entwickelt in den
70er Jahren für die Gebäude-Architektur und Städteplanung
[1], hat das Schlagwort Entwurfsmuster
(Design Patterns) geprägt. Es war wohl die Suche nach der Konzeption
eines Architektur-Handbuchs für den Software-Entwurf (OOPSLA
92), die zur alexandrinischen Musterform führte. 1995
hieß das bestverkaufte Buch der Informatik Design Patterns:
Elements of Reusable Object-Oriented Software" [6].
Der Musterbegriff hat eine Bewegung ausgelöst, die ihresgleichen
sucht (http://st-www.cs.uiuc.edu/users/patterns/patterns.html).
Internationale Workshops finden bereits turnusmäßig statt:
Pattern Languages of Program Design [4], PLoP
9496, EuroPLoP 96.
Alltagssprachlich verstehen wir unter einem Muster: eine Vorlage,
nach der etwas hergestellt wird, ein beispielhaftes Vorbild oder
eine regelmäßige, sich wiederholende Struktur. In allen
drei Interpretationen wird der Begriff in der (objektorientierten) Softwaretechnik
angewandt:
- konstruktiv als Vorlage (generische Entwurfsmuster),
- deskriptiv als Vorbild für die Dokumentation von Entwurfsentscheidungen
und -kompromissen (http://www.ti.et-inf.uni-siegen.de/Entwurfsmuster)
und
- strukturell als Orientierung in einem komplexen Entwurf.
Entwurfsmuster sind praxisbewährte Lösungsstrukturen für
stereotype Entwurfsprobleme. Im Gegensatz zu Halbfabrikaten wie Klassenbibliotheken
und Frameworks, werden immaterielle Entwürfe wiederverwendbar.
Die handlungsorientierte Musterform macht das Erfahrungswissen
der Experten leichter zugänglich. Zur Disposition des Entwerfers
stehen nicht mehr nur einzelne Klassen, sondern vielmehr Konfigurationen
mehrerer Klassen Mikro-Architekturen.
Beispiel: Der Entwurf einer grafischen Oberfläche wäre
ohne die Orientierung an Erfahrungswerten mühsam, ad hoc und fehlerträchtig.
Ein mustergestützter Entwurf könnte nun folgendermaßen
verlaufen: Wir definieren zunächst unser konkretes Problem (z.B.
die Entkopplung unterschiedlicher, aber konsistenter Visualisierungen
desselben Datenbestands) und suchen dann in einem Musterbuch nach
geeigneten Vorlagen. Wir finden ein strategisches Muster namens
Model-View-Controller" (MVC, Abb. 1) und erfahren, daß
es sich in interaktiven Grafikanwendungen bewährt hat. Auf wenigen
Seiten werden dort das immer wiederkehrende Entwurfsproblem, der
Anwendungskontext und eine Lösungsstruktur beschrieben.
|
Abb. 1 Illustration zum MVC-Muster [6]
|
Die grafischen und textuellen Erläuterungen sind anschaulich und
intuitiv. Wir erfahren, wie die Dreiteilung (der Controller für die Abfrage
und Steuerung der Benutzeraktionen ist für unser Beispiel nicht relevant)
die ehernen Entwurfsprinzipien der Softwaretechnik umsetzt (Information
hiding von Parnas und schwache Kopplung zwischen und starke Kohäsion
in den Modulen von Simon [7]). Dazu werden
wir auf feinkörnigere taktische Muster verwiesen, die immer
nach den gleichen Kriterien beschrieben sind: Mustername und Synonyme,
Einordnung, Zweck und Einsatzmotive, Anwendungs-Szenarien, allgemeine
Lösungsstruktur, beteiligte Klassen und deren Zusammenspiel, Vor-
und Nachteile, Beispiele und Nachweise über den erfolgreichen Praxiseinsatz,
Querverweise und Abgrenzungen zu ähnlichen Mustern.
Ein solches Taktikmuster heißt Publisher-Subscriber"
(Klassendiagramm in Abb. 2). Es beschreibt die Korrelation zwischen dem
zentralen Datenbestand (model) und den verschiedenen Sichten (views).
Das Publisher"-Objekt unterrichtet alle Subscriber"-Objekte
über Zustandsänderungen (NotifySubscribers()), indem es deren
Aktualisierung (Update()) veranlaßt. Dabei sind die Subscriber"-Objekte
untereinander entkoppelt und vollständig austauschbar (dynamisch
zur Programmlaufzeit). Das Muster beschreibt also eine 1-zu-n-Abhängigkeit
zwischen Objekten. So läßt sich zum Beispiel ein zentraler
Datenbestand (in der Publisher-Rolle) auf verteilten Rechnern oder in
mehreren Fenstern" desselben Rechners unterschiedlich darstellen:
als Kuchen-, Balkendiagramme oder Tabellen (Subscriber-Rollen).
|
Abb. 2 Publisher-Subscriber-Muster
|
Viele der Muster, wie Publisher-Subscriber, stammen aus GUI-Frameworks
(ET++, HotDraw, InterViews). Es waren erfahrene Framework-Entwickler (Autoren
von [6]), die die Musterform favorisierten. Muster
zur Framework-Dokumentation legen das Erfahrungswissen der Entwickler
offen und verringern so den Lern- und Einarbeitungsaufwand für den
Framework-Anwender.
Softwaremuster sind allgemein kein originär akademisches Thema, vielmehr
gehen sie aus der industriellen Praxis hervor. Immer mehr Softwarehäuser
versuchen, ihren langjährigen Erfahrungsfundus in (hausinternen)
Musterbüchern zu dokumentieren. Derzeit publizierte Musterbücher
unterscheiden sich hauptsächlich in ihrem Abstraktionsgrad.
So gibt es Muster für die Systemanalyse [5],
für den Programmentwurf [6] und für
die Codierung [3].
Das thematische Spektrum der Entwurfsmuster legt eine Bestandsaufnahme
in komprimierter Form nahe: ETHOS [7].
E wie economic":
Bekanntlich liegt das Potential der Objektorientierung in der Wiederverwendung.
Die Kapselung von Daten und Operationen erlaubt die systematische
Wiederverwendung von Struktur und Verhalten in einer Komponente, der Klasse.
Entwurfsmuster erweitern nun die Wiederverwendung auf kommunizierende
Gruppen von Klassen. Wiederverwendung findet im großen"
statt, das heißt auf einer architektonischen Ebene, ähnlich
der eines Frameworks. Im Gegensatz dazu sind Entwurfsmuster aber abstrakt
(kein Code) und somit anwendungsunabhängig. Sie sind deshalb gut
geeignet, ein Framework zu dokumentieren.
T wie technical":
Die Form eines Softwaremusters wird derzeit noch kontrovers diskutiert.
Die alexandrinische Urform, das Triplett aus Problem, Kontext und
Lösung, ist narrativ, von epischer Breite. Die Portland"-Softwaremuster
halten diese Form weitestgehend ein (http://c2.com/ppr/about/portland.html)
. Die Gamma-Muster" sind schematischer, sie werden nach 13
Kriterien beschrieben (wie in unserem Beispiel). Nach der Granularität
der Lösungsstruktur lassen sich zwei Kategorien unterscheiden: Sprachspezifische
Codierungs-Muster stellen die kleinste Kategorie: Idiome [3]
(syntaktische Strukturen). Gamma-Muster dagegen sind grobkörniger
(Strukturen aus 3 4 Klassen), sie unterstützen den allgemeinen
Programmentwurf.
Das ideale Medium für Entwurfsmuster ist Hypertext, da ein Muster
nicht isoliert auftritt, sondern stets assoziativ im Verbund, und die
Navigation im Informationsraum Voraussetzung für deren effiziente
Verwendung ist. Alexander spricht hier von Mustersprachen (treffender
wäre wohl Begriffssysteme); Buschmann et al. sprechen von Mustersystemen
[2]. Musterbücher werden schon bald ihre
Gutenberg-Form überwinden; Proprietäre Entwurfsmuster (also
solche, die firmenspezifisches Knowhow widerspiegeln) werden in Intranetzen,
nichtproprietäre im Internet verfügbar gehalten.
H wie human":
Lernpsychologisch sind Entwurfsmuster Problem-Lösungspaare gleicher
Struktur, die primär auf den Erwerb von Fertigkeiten ausgerichtet
sind. Sie werden bereits als didaktisches Vehikel in der industriellen
Schulung und der akademischen Lehre eingesetzt (http://st-www.cs.uiuc.edu/users/patterns/Education.html).
Motivations-psychologisch steigern Entwurfsmuster das Selbstwertgefühl
des Programmierers: Orientiert er sich an den Entwurfsmustern eines Experten,
dokumentiert er damit die Qualität seines Programms und distanziert
sich zugleich vom Hackertum".
O wie organizational":
Derzeit sind Bemühungen im Gange, die bewährten Prinzipien
und Strategien der Projektführung und der Teamorganisation in Musterform
zu beschreiben [4]. Das Wissen über gute
Organisationsformen entbehrt bisher der pragmatischen Vermittlung. Organisationsmuster
versprechen hier Abhilfe.
S wie social":
Mit Hilfe der Entwurfsmuster wird ein gemeinsames Vokabular geschaffen,
das eine effiziente Kommunikation unter den Entwerfern erlaubt und so
die Diskussion über komplexe Zusammenhänge erleichtert. Originalton
aus einem Projekt-Meeting:
Nehmen wir an dieser Stelle das Publisher-Subscriber-Muster,
um die Komponenten zu entkoppeln."
Für sprachkundige Entwerfer, die das gleiche Mustervokabular
beherrschen, ist damit alles gesagt!
Gesamtbewertung:
Die literarische Gattung Musterbuch kann auf eine lange Tradition
verweisen. Sie hat ihre Anfänge nicht erst bei Christopher Alexander.
Für die Entwicklung des Handwerks und der Industrie im 19. Jahrhundert
waren Musterbücher von grundlegender Bedeutung. Sie stellten ein
Kompendium handwerklichen Wissens dar. In ihnen wurden die über die
Jahrhunderte entwickelten und gesammelten Erfahrungen festgeschrieben.
Die heutigen Handwerke entwickeln sich wesentlich schneller und unterliegen
viel stärker dem Wandel der Technik. Auch der Software-Entwurf wurde
immer schon als Handwerkskunst verstanden im guten Sinne
als Kunsthandwerk: Computer Programming as an Art" (Knuth),
im schlechten Sinne als Spezialistentum: kryptische Programme,
die nur der Künstler" selbst warten kann. Mit Hilfe von
Musterbüchern à la Gamma et al. können wir fortan die
gute Kunst des Software-Handwerks beschreiben und vor allem lehren.
Artikelanfang Seitenanfang
|
|
Literatur
- Alexander, C. et al.: A Pattern Language: Towns,
Buildings, Construction. New York: Oxford University Press 1977
- Buschmann, F. et al.: Pattern-Oriented Software
Architecture: A System of Patterns. Chichester: Wiley & Sons 1996
- Coplien, J. O.: Advanced C++ Programming Styles
and Idioms. Reading MA: Addison-Wesley 1991
- Coplien, J. O.; Schmidt, D. C. (Hrsg.): Pattern
Languages of Program Design. Reading MA: AddisonWesley 1995
- Fowler, M.: Analysis Patterns: Reusable Object
Models. Reading MA: Addison-Wesley 1996
- Gamma, E. et al.: Design Patterns: Elements
of Reusable Object-Oriented Software. Reading MA: Addison-Wesley 1995,
5. Druck
- Quibeldey-Cirkel, K.: Das Objekt-Paradigma
in der Informatik. Stuttgart: Teubner 1994
Artikelanfang Seitenanfang
|
|
Autor & Copyright
Klaus Quibeldey-Cirkel
Universität Siegen,
Technische Informatik,
Hölderlinstrasse 3,
D-57068 Siegen,
Tel 0271/7403210, Fax 0271/7403344
quibeldey@ti.et-inf.uni-siegen.de
© 1996 Informatik Spektrum, Springer-Verlag Berlin Heidelberg
Artikelanfang Seitenanfang
|
Expertensystemshell-Baukasten
|
Erläuterung
Wiederverwendung möglichst mächtiger Komponenten ist ein wesentlicher
Schlüssel zur kosteneffektiven Entwicklung von Informationssystemen.
In diesem Kontext ist die enorme Popularität von VisualBASIC in der
WINDOWS-Welt zu sehen, für das eine Vielzahl von sogenannten Custom
Controls (VBX) oder OLE Controls (OCX) zur Verfügung stehen [1].
Diese können, korrekte Funktionsweise vorausgesetzt, die Anwendungsentwicklung
wesentlich beschleunigen.
Auch im Expertensystembereich wurde die Bedeutung von Wiederverwendung
relativ früh erkannt und eine Vielzahl von Werkzeugen auf unterschiedlichen
Abstraktionsniveau erstellt. Allgemeine, nicht problemspezifische Expertensystemwerkzeuge
wie KAPPA oder SMART ELEMENTS erlauben zwar die Wiederbenutzung in Form
von Regelinterpretern oder Objektsystemen, liegen jedoch auf einer sehr
implementierungsnahen Ebene und bieten wenig konzeptionelle Unterstützung
zur Realisierung der Problemlösung und für die Wissensakquisition.
Zwischen den zur Verfügung gestellten Mechanismen und dem Denken
des Experten klafft die oft beklagte Knowledge-Engineering-Lücke.
Wesentlich erfolgversprechender ist die Entwicklung und Wiederbenutzung
von konzeptuellen Modellen z.B. in Form von starken Problemlösungsmethoden,
die eine modellbasierte Wissensakquisition erlauben.
Problemspezifische Expertensystemshells, die auf der Implementierung
einer starken Problemlösungsmethode beruhen, erreichen einen sehr
hohen Grad an Wiederverwendung. Im günstigsten Fall ist bei der Nutzung
eines solchen Werkzeuges keine Implementierung in der zugrundeliegenden
Programmiersprache nötig, der Aufwand zur Systemerstellung beschränkt
sich auf den Aufbau der Wissensbasis. Durch das festgelegte Modell der
Problemlösung ist es möglich, grafische Wissensakquisitionssysteme
zu entwickeln, die von der internen Struktur der Wissensbasis abstrahieren
und es Experten des Anwendungsbereichs nach kurzer Einarbeitungszeit erlauben,
Expertensysteme selbständig ohne die Unterstützung durch eine
Wissensingenieurin oder einen Wissensingenieur aufzubauen. Diese direkte
Wissensakquisition durch Experten hat eine Reihe von signifikanten Vorteilen:
Zum einen entfallen die üblichen Transfer- und Übersetzungsprobleme
zwischen Wissensingenieur und Experte, zum anderen wird die Wartung immens
erleichtert, die sonst von der weiteren Verfügbarkeit des Wissensingenieurs
abhinge.
Obwohl problemspezifische Shells enorme Vorteile bieten, sofern sie
für eine Anwendung geeignet sind, sind sie jedoch auf nur ein Modell
der Problemlösung beschränkt und bezüglich der Integration
neuer Mechanismen sehr unflexibel. Das kann dazu führen, daß
Expertenwissen in unnatürlicher Weise umformuliert werden muß
oder gar einen Werkzeugwechsel bedingen, so daß ein Irrtum bei der
Werkzeugauswahl sehr hohe Kosten verursacht.
Expertensystemshell-Baukästen (Shell-Baukästen) stellen einen
sehr attraktiven Kompromiß dar, der die Vorteile von problemspezifischen
Shells beibehält, aber deren Flexibilität und damit auch das
Einsatzspektrum deutlich erhöht. Die wesentlichen Ideen dabei sind
die anwendungsspezifische Konfiguration von Problemlösungsmethoden
und die Generierung zugehöriger Wissensakquisitionswerkzeuge.
Zur Konfigurierung einer Problemlösungsmethode werden die Methoden
nicht mehr als monolithischer Block dargestellt und realisiert, sondern
in kleinere Bausteine zerlegt. Zu einzelnen Bausteinen oder Unterbausteinen
können alternative Realisierungen angegeben werden, so daß
sich ein Konfigurationsbaum aus Aufgaben und Teilaufgaben ergibt, die
jeweils von einer oder mehreren Methoden gelöst werden. Dieser Baum
kann leicht um neue Realisierungsalternativen erweitert werden. Zusätzlich
zu diesem Baum ist natürlich auch die Kontrolle und insbesondere
die Wissensrepräsentation der Methoden zu spezifizieren. Sofern die
Wissensrepräsentationen der zusammengehörigen Methoden nicht
direkt verträglich sind, müssen entsprechende Abbildungsvorschriften
angegeben werden, die das Wissen entsprechend transferieren. Zur Auswahl
einer konkreten Problemlösungsmethode wird dann das Konfigurationsproblem
gelöst, also Entscheidungen für alle Alternativen getroffen.
Diese Entscheidungen können z.B. aufgrund der Verfügbarkeit
von Wissen oder Laufzeitanforderungen an das System getroffen werden.
Falls keine zufriedenstellende Konfiguration gefunden werden kann, ist
der Konfigurationsbaum entsprechend zu erweitern. In Abb. 1 findet sich
ein Konfigurationsbaum für die Diagnostik.
|
Abb. 1 Ausschnitt aus einem Konfigurationsbaum für Diagnostik. Diagnostik besteht in der gewählten Methode aus einem Zyklus von Testauswahl, Datenerfassung, Datenabstraktion und Diagnostischer Interpretation. Zur Interpretation stehen 6 alternative Methoden zur Verfügung. Weiter verfeinert ist der Fallvergleich, der sich aus der Bestimmung ähnlicher Fälle, etwa durch Gewichtete Merkmale oder durch Hillclimbing über Nachbarschaften, und einem anschließenden Lösungstransfer zusammensetzt.
|
Beispiele für solche Shell-Baukästen sind etwa PLA-KON bzw.
KONWERK im Bereich des Planens und Konfigurierens [2,
3], COKE für die Zuordnung und D3 für
die Diagnostik [4, 5].
Noch attraktiver werden Shell-Baukästen in Zusammenhang mit der
Generierung eines zugehörigen Wissensakquisitionssystems, da dessen
manuelle Erstellung einen immensen Zeitaufwand bedeutet. Zur Generierung
bietet es sich an, von einer Wissensbasis auszugehen, die aus Instanzen
vorgegebener Objekttypen besteht. Diese Objekttypen haben eine Reihe von
Attributen mit einem fest vorgegebenen Wertebereich, wie z.B. Aufzählungstyp,
Zahl, etc., dessen syntaktischer und teilweise auch semantischer Aufbau
durch eine (attributierte) Grammatik beschrieben werden kann. Zwischen
den Objekttypen können Relationen bestehen, die ebenfalls in der
Grammatik spezifiziert werden.
Des weiteren sollte ein Wissensakquisitionssystem vollständig aus
einer Reihe von vorgegebenen generischen Wissenseditoren wie Formularen
zur Eingabe von lokalem Wissen und Hierarchien, Übersichts-, Attribut-
und Detailtabellen zur Eingabe von Beziehungswissen, zusammengesetzt werden
können. Für jeden Wissenseditor kann der Zusammenhang zwischen
interner Darstellung, etwa ein Attribut mit einem Aufzählungstyp,
und der externen Darstellung, etwa ein Popup-Menü, angegeben werden.
Bei der Akquisition von Relationswissen ist der Zusammenhang natürlich
etwas komplizierter. Zusammen mit dieser Information kann dann ein Wissenseditor
durch Angabe der zu akquirierenden Typen, Attribute und Relationen vollständig
spezifiziert und generiert werden [6, 7].
Wenn die Wissensrepräsentation aller Bausteine des Konfigurationsbaumes
in der so angegebenen Weise um Wissen für ihre Akquisition erweitert
worden ist, kann für eine neue Problemstellung ein anwendungsspezifisches
Expertensystemwerkzeug mit einer grafischen Wissensakquisitionskomponente
weitgehend automatisch generiert werden. Diese erhöhte Flexibilität
macht nun ein gegenüber der Benutzung von monolithischen Expertensystemwerkzeugen
verfeinertes Prozeßmodell (Abb. 2) möglich.
|
Abb. 2 Prozeßmodell bei Verwendung eines Shell-Baukastens
|
Während die Expertin oder der Experte bei problemspezifischen Shells
nach der Auswahl des geeignetsten Werkzeuges keinen weiteren Einfluß
auf das Wissensmodell und das Wissenserwerbssystem hatte, können
nun die gewonnenen Erfahrungen beim Aufbau und der Evaluation der Wissensbasis
dazu benutzt werden, um das Werkzeug optimal an die konkreten Anforderungen
und Bedürfnisse anzupassen. Die beiden Prozesse des Verfeinerns und
Evaluierens der Wissensbasis und des Anpassens der Shell laufen dann in
zwei miteinander verbundenen Zyklen ab, wie in Abb. 2 angedeutet.
Artikelanfang Seitenanfang
|
|
Literatur
- Hüskes, R.: Baukasten-Software, c’t (6), (1994),
214 – 220
- Syska, I: Modulare Architekturen für Konstruktionssysteme.
Dissertation, Universität Hamburg, (1992), DISKI 4, INFIx
- Günter, A.: KONWERK – ein modulares Konfigurierungswerkzeug,
Expertensysteme 95, PAI 2, INFIX, (1995), 1 -18
- Poeck, K.: Konfigurierbare Problemlösungsmethoden
am Beispiel der Problemklassen Zuordnung und Diagnostik. Dissertation,
Universität Würzburg, (1996), DISKI 86, INFIX
- Puppe, F.; Poeck, K.; Gappa, U.; Bamberger,
S.; Goos, K.: Wiederverwendbare Bausteine für eine konfigurierbare Diagnostik-Shell.
Kl (2), (1994), 13 – 18
- Puerta, A. R.; Egar, J. W.; Tu, S. W.; Musen,
M. A.: A multiplemethod knowledgeacquisition shell for the automatic
generation of knowledgeacquisition tools. Knowledge Acquisition (4),
(1992), 171 – 196
- Gappa, U.: Grafische Wissensakquisitionssysteme
und ihre Generierung. Dissertation, Universität Karlsruhe, (1996), DISKI
100, INFIX
Artikelanfang Seitenanfang
|
|
Autor & Copyright
Karsten Poeck,
Deutsche Bank,
OuB(Z), EDV-Orga, RBS-NOS,
Alfred-Herrhausen-Allee 10,
65760 Eschborn
© 1996 Informatik Spektrum, Springer-Verlag Berlin Heidelberg
Artikelanfang Seitenanfang
|
Extremes Programmieren (XP)
Kurzinfo In
diesem Artikel wird gezeigt, welche Ideen hinter XP stehen, aus welchen
Techniken XP besteht und welche Voraussetzungen für eine Implementierung
von XP gegeben sein müssen. Darüber hinaus werden auch Schwachpunkte und
Grenzen des XP-Ansatzes beleuchtet.
|
Erläuterung
Extremes Programmieren (Extreme Programming, XP) ist ein Prozessmodell
für die objektorientierte Software-Entwicklung. Wie der Name andeutet,
handelt es sich um ein codezentriertes Prozessmodell, bei dem bestimmte
Techniken in extremem Maße angewendet werden. Einige Annahmen und
Techniken von XP stehen in starkem Widerspruch zum Software Engineering,
das vom Capability Maturity Model und ISO 9000 geprägt ist. Diese
Widersprüche führen zu lebhaften Diskussionen über diverse
Aspekte von XP.
Das extreme Programmieren wurde von Kent Beck, Ward Cunningham und Ron
Jeffries entworfen und durch Erprobung in Projekten weiterentwickelt.
XP ist gedacht für kleinere Projekte mit unklaren und sich immer
wieder ändernden Anforderungen. Der Kunde hat gleichzeitig hohe Ansprüche
an die Qualität der Software.
Praktiken
XP ist ein Prozessmodell, das sich durch eine Reihe von Techniken auszeichnet,
die in der XP-Terminologie Praktiken heißen. Diese Praktiken sind
nur in ihrer Gesamtheit sinnvoll. Das Weglassen wichtiger Praktiken kann
zum Scheitern des XP-Ansatzes führen, da sich die Praktiken gegenseitig
stützen. Keine der eingesetzten Praktiken ist wirklich neu; neu ist
die Kombination und der extreme" Grad, in dem diese Praktiken
eingesetzt werden.
Kleine Releases
Aufgrund der sich ständig ändernden Anforderungen wird ein hochgradig
iterativer Entwicklungsprozess mit einen Release-Zyklus von 1–3 Monaten
angestrebt. Ein Release besteht aus mehrere Iterationen von 1–3 Wochen
Dauer. Die Iterationen wiederum zerfallen in Arbeitpakete mit einer Dauer
von 1–3 Tagen. Nach jeder Iteration kann der Kunde Abweichungen von seinem
Wünschen feststellen und korrigieren. Das erste Release sollte bereits
ein funktionierendes Kernsystem sein, das dann in weiteren Releases inkrementell
ausgebaut wird.
Planungsspiel
Die Planung der Iterationen erfolgt im Planungsspiel. Ziel des Spieles"
ist es, für die kommende Iteration aufgrund vorgegebener Spielregeln
die verfügbaren Entwicklungsressourcen und die Kundenwünsche
in Einklang zu bringen. Die Anforderungen werden in Form so genannter
Storys niedergelegt. Das sind rudimentäre Anwendungsfälle, die
auf eine Karteikarte geschrieben werden.
Der Kunde versieht seine Storys mit Prioritäten. Er bestimmt, welche
Storys in der kommenden Iteration zu implementieren sind und wann die
Iteration abgeschlossen sein soll. Daraufhin geben die Entwickler Schätzungen
ab, wie viel Aufwand zur Implementierung notwendig sein wird. Wahrscheinlich
wird der Aufwand die verfügbaren Ressourcen übersteigen, so
dass der Kunde einige Storys auf spätere Iterationen verschieben
muss.
Dies wird so lange wiederholt, bis ein Gleichgewicht erreicht ist. Auf
diese Weise gelangt man zu einer relativ realistischen Planung für
die kommende Iteration. Falls die Schätzungen der Entwickler daneben
lagen, kann bei Bedarf nachverhandelt werden.
Tests
Automatisierte Tests spielen die zentrale Rolle bei XP; ohne sie ist
XP nicht realisierbar. Da außer den Storys keine Spezifikation des
Systems und seiner Bestandteile vorliegt, wird das Wissen über die
gewünschte Funktion in Testfällen niedergelegt. Die Entwickler
schreiben Tests für ihre Klassen (unit tests). Der Kunde entwickelt
Testfälle für seine Storys (functional tests), die von einem
Tester in Tests umgesetzt werden. Die Testfälle werden so implementiert,
dass sich alle Tests jederzeit automatisch ausführen lassen.
Wichtig ist, dass die Entwickler erst die Tests schreiben und dann implementieren.
Das zwingt sie dazu, eine rudimentäre Spezifikation der zu testenden
Funktionen in Form von Fallbeispielen anzugeben. Sobald dann die Implementierung
vorliegt, kann sie gegen die Tests geprüft werden.
Systemmetapher
Die Systemmetapher steht für die grundsätzliche Idee hinter
der Architektur des Systems. Sie soll sowohl für die Entwickler als
auch für den Kunden verständlich sein. Die Systemmetapher soll
dazu dienen, einen Architekturentwurf zu ersetzen; statt dessen sollen
sich die Entwerfer beim Entwerfen von der Systemmetapher leiten lassen.
Einfacher Entwurf
Beim Entwurf soll immer nach einer einfachen Lösung gesucht werden,
die nur die momentan anstehenden Anforderungen abdeckt. Beck nennt das
the simplest thing that could possibly work" [1].
Zukünftige Erweiterungen sollen zunächst nicht berücksichtigt
werden, da sich die Anforderungen ändern können, wodurch sich
die zusätzlich eingebaute Flexibilität als nutzlos erweist.
Sollten später Änderungen notwendig sein, wird der Entwurf refaktorisiert.
Refaktorisierung
Refaktorisierung dient zur Vereinfachung des Entwurfs eines bestehenden
Systems unter Beibehaltung der Semantik. Dabei soll die Verständlichkeit
und die Änderbarkeit des Codes verbessert werden.
Da die gewünschte Semantik in den Tests niedergelegt ist, kann
nach einer Refaktorisierung durch Test geprüft werden, ob dabei Fehler
unterlaufen sind. (Näheres zum Vorgehen bei Refaktorisierung findet
sich in [4]).
Laut Beck lässt sich beobachten, dass ein großer Teil der
Dokumentation, die erstellt wird, mangels laufender Anpassung sehr schnell
veraltet und daher gar nicht benutzt wird. Deshalb beschränkt XP
die Dokumentation auf den Code selbst. Dieser muss daher in hohem Maße
selbsterklärend sein. Die Selbsterklärungsfähigkeit soll
vor allem aus der Struktur und der Namensgebung kommen. Wenn der Code
an einer Stelle eines erklärenden Kommentars bedarf, sollte so refaktorisiert
werden, dass der Code auch ohne Kommentar verständlich ist.
Programmieren in Paaren
Programmieren in Paaren (pairprogramming) ist die zweite zentrale Praktik
von XP. Entwurf, Codierung und Test werden von zwei Entwicklern gemeinsam
durchgeführt. Während einer der beiden Entwickler programmiert,
prüft der Partner den Code auf Schreibfehler und logische Fehler.
Außerdem behält er andere Ziele im Auge, z.B. ob der Code zum
Entwurf passt, der Entwurf verbessert werden kann oder ob zu dem Code
noch Tests fehlen. Auf diese Weise werden der Code, der Entwurf und die
Tests einer kontinuierlichen Begutachtung unterzogen. Bei Bedarf tauschen
die beiden Entwickler die Rollen.
Die Paarbindung ist nicht fest, sondern man sucht sich für jedes
Arbeitspaket einen geeigneten Partner aus. Die dynamische Paarbildung
hat den positiven Nebeneffekt, dass sich das Wissen über alle Aspekte
des Systems auf alle Entwickler verbreitet. Wenn ein Entwickler ausfällt,
kann er daher relativ problemlos ersetzt werden.
Williams et al. [6] haben die Auswirkungen des
Programmieren in Paaren empirisch untersucht. Ihrer Untersuchung zufolge
nimmt der Entwicklungsaufwand im Vergleich zu allein arbeitenden Entwicklern
nur leicht zu (um etwa 10%), während der Code besser verständlich
ist und viel weniger Fehler aufweist.
Gemeinsames Code-Eigentum
Der entstehende Code gehört nicht einem bestimmten Entwickler,
sondern allen Entwicklern im Projekt. Das bedeutet, dass jedes Entwicklerpaar
jederzeit überall Änderungen vornehmen darf, um z.B. die Verständlichkeit
des Codes zu verbessern. Dabei besteht natürlich die Gefahr, dass
die Änderungen fehlerhaft sind. Daher muss das Paar nach jeder Änderung
alle Tests laufen lassen.
Kontinuierliche Code-Integration
Neu entwickelter oder geänderter Code wird alle paar Stunden in
die aktuelle Code-Basis integriert. Zur Integration dient ein dedizierter
Integrationsrechner. Dort spielt ein Paar seine Änderungen ein und
lässt danach alle Tests laufen. Treten dabei Fehler auf, muss das
Paar seine Änderungen zurücknehmen oder dafür sorgen, dass
alle Fehler behoben werden. Auf diese Weise ist immer ein lauffähiges
System verfügbar. Außerdem zerfallen durch das Vorgehen die
Arbeitspakete in kleine, überschaubare Teile.
40-Stunden-Woche
Das Programmieren in Paaren stellt hohe Ansprüche an die Partner.
Beide müssen jederzeit hoch konzentriert bei der Sache sein. Das
können sie aber nicht, wenn sie erschöpft sind. Daher werden
bei XP geregelte Arbeitszeiten gefordert (die 40 Stunden sind dabei nur
ein Richtwert). Überstunden, hier definiert als unfreiwillige Mehrarbeit,
sollen nur in Ausnahmefällen gemacht werden.
Kundenvertreter im Team
Da keine echte Spezifikation vorhanden ist, gibt es viele Rückfragen
an den Kunden. Daher muss ein Vertreter des Kunden für die Entwickler
permanent verfügbar sein (onsite customer). Es soll sich um einen
zukünftigen Anwender des Systems handeln. Der Kundenvertreter entwickelt
die Testfälle für die funktionalen Tests.
Programmierrichtlinien
Um das Arbeiten in Paaren und das gemeinsame Code-Eigentum zu erleichtern,
halten sich alle Entwickler an feste Programmierrichtlinien. Diese werden
von den Entwicklern untereinander vereinbart und strikt eingehalten. Auf
diese Weise erhält man einheitlichen Code, der von allen verstanden
und geändert werden kann.
Voraussetzungen
Wie man den einzelnen Praktiken entnehmen kann, hat XP einige Voraussetzungen
für eine erfolgreiche Implementierung:
- Die Änderungskosten steigen höchstens logarithmisch mit
der Zeit. Ansonsten wird der Ansatz des einfachsten Entwurfs durch die
ständige Refaktorisierung zur Integration neuer Anforderungen zu
teuer.
- Das Management, alle Teammitglieder und der Kunde müssen sich
auf die XP-Praktiken einlassen. Außerdem muss der Kunde in der
Lage sein, einen qualifizierten Mitarbeiter abzustellen.
- Das Entwicklerteam darf nicht zu groß sein. Bei 1015 Entwicklern
liegt die Obergrenze.
- Die Entwickler sind an einem Ort konzentriert und haben die gleichen
Arbeitszeiten, da sonst Kommunikation und Paarbildung erschwert sind.
- Die Testfälle müssen automatisch und in kurzer Zeit ausführbar
sein. Lange Übersetzungs- und Ausführungszeiten sind von großem
Nachteil.
Beck empfiehlt eine schrittweise Einführung von XP. Es sollte immer
nur eine Praktik auf einmal eingeführt werden, und zwar immer diejenige,
die das momentan dringlichste Problem angeht [1].
Natürlich sind dabei die Abhängigkeiten der Praktiken untereinander
zu berücksichtigen.
Bewertung
Wie bereits erwähnt, mangelt es nicht an Kritik am extremen Programmieren
(siehe z.B. [5]). Einige Punkte sollen hier herausgegriffen
werden.
- Das Fehlen einer expliziten Spezifikation und einer Entwurfsdokumentation
ist besonders kritisch. Es gibt zwar die Dokumentation in Form der Testfälle
und des Codes, doch ist es zweifelhaft, ob diese allein auch für
Entwickler ausreicht, die nicht Mitglied im XP-Team waren. Ohne die
beteiligten Entwickler geht es vermutlich nicht.
- Das gemeinsame Code-Eigentum kann zu einigen Problemen führen.
Die Entwickler müssen mangels eines Übersichtsdokuments den
Entwurf als mentales Modell im Kopf haben. Ändert ein anderer Entwickler
den Entwurf im Code, muss das mentale Modell angepasst werden, da sonst
mit falschen Voraussetzungen codiert wird und dadurch Fehler entstehen.
Außerdem kann es zu konkurrierenden Änderungen an denselben
Klassen kommen, was zu Integrationsproblemen führt.
- Darüber hinaus ziehen Änderungen am Entwurf in der Regel
auch Änderungen an den Tests nach sich. Da viele XP-Praktiken voraussetzen,
dass die Tests korrekt sind, muss hier besonders sorgfältig gearbeitet
werden. Ob die Begutachtung beim Programmieren in Paaren wirklich ausreicht,
die Schwächen des Testansatzes zur Qualitätssicherung zu kompensieren,
ist fraglich.
- Problematisch ist, dass XP bisher nur unzureichend dokumentiert ist,
insbesondere wenn es um die konkrete Umsetzung geht. Zum Beispiel ist
das Konzept der Systemmetapher reichlich nebulös. Es gibt auch
keine Daten, die nachweisen, dass XP anderen Vorgehensweisen überlegen
ist. Empirische Untersuchungen wurden bisher nicht durchgeführt.
Andererseits gibt es viele (Jubel-)Berichte aus Projekten, in denen
XP eingesetzt wurde. Das bekannteste Projekt ist das C3-Projekt bei DaimlerChrysler
[3].
Bei Beck [2] finden sich auch Berichte aus anderen
Projekten. Aus den Berichten geht hervor, dass alle beteiligten Gruppen
mit XP zufrieden sind. Entwickler berichten von hoher Motivation und Freude
bei der Arbeit, das Management freut sich über die gute Termineinhaltung,
und die Kunden begrüßen die frühe Verfügbarkeit eines
funktionierenden Systems sowie die hohe Qualität.
Weitere Informationen zu XP finden sich im Referenzwerk von Kent Beck
[1] und unter www.xprogramming.com.
An der Diskussion teilnehmen kann man in den News-Gruppen comp.object
und comp.software-eng sowie in den Mailing-Listen xp-forum
und extremeprogramming bei www.egroups.com.
Artikelanfang Seitenanfang
|
|
Literatur
- Beck, K.: Extreme Programming Explained: Embrace
Change. Reading/MA: AddisonWesley 1999
- Beck, K.: Embracing Change with Extreme Programming.
IEEE Computer 32(10), 70–77 (1999)
- C3 Team: Chrysler Goes to „Extremesº. Distributed
Computing, Oktober 1998, 24–28
- Fowler, M.: Refactoring: Improving the Design
of Existing Code. Reading/MA: AddisonWesley 1999
- Wegener, H.: Extreme Ansichten: Für und Wider
des Extreme Programming. iX 12, 126–130 (1999)
- Williams, L.; Kessler, R.; Cunningham, W.;
Jeffries, R.: Strengthening the Case for Pair-Programming. (Erscheint
in IEEE Software; s. auch
www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF)
Artikelanfang Seitenanfang
|
|
Autor & Copyright
Ralf Reißing
Universität Stuttgart,
Institut für Informatik,
Abteilung Software Engineering,
Breitwiesenstr. 20–22,
D-70565 Stuttgart
reissing@informatik.unistuttgart.de
© 2000 Informatik Spektrum, Springer-Verlag Berlin Heidelberg
Artikelanfang Seitenanfang
|
|
 |
|
|