Abb. 1 Funktionsweise der elektronischen Tinte der Unternehmen Gyricon media und E Ink [4]
Informatik-Lexikon
E
e-Business
Elektronisches Papier
Entwurfsmuster
Expertensystemshell-Baukasten
Extremes Programmieren (XP)
|
|
Autor & Copyright © 2002 Informatik Spektrum, Springer-Verlag Berlin Heidelberg |
Elektronisches Papier
ErläuterungDie 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 TinteNicholas 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. |
|
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 PapiersDas 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]:
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]. WeiterentwicklungenUnabhä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). |
|
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. |
Hinweis: Die URLs entsprechen dem Stand bei der Veröffentlichung des Artikels und werden nicht aktualisiert. |
Entwurfsmuster |
ErläuterungDer 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 ’94–’96, 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:
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. 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:
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. |
Expertensystemshell-Baukasten |
ErläuterungWiederverwendung 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. |
|
Autor & Copyright |
ErläuterungExtremes 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. PraktikenXP 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 ReleasesAufgrund 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. PlanungsspielDie 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. SystemmetapherDie 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 EntwurfBeim 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. RefaktorisierungRefaktorisierung 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 PaarenProgrammieren 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-EigentumDer 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-IntegrationNeu 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-WocheDas 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 TeamDa 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. ProgrammierrichtlinienUm 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. VoraussetzungenWie man den einzelnen Praktiken entnehmen kann, hat XP einige Voraussetzungen für eine erfolgreiche Implementierung:
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. BewertungWie bereits erwähnt, mangelt es nicht an Kritik am extremen Programmieren (siehe z.B. [5]). Einige Punkte sollen hier herausgegriffen werden.
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. |
|