Case ist die Abkürzung von Computer Aided (oder Assisted) Software Engineering und drückt aus, daß die Entwicklung von Software durch computergestützte Software-Entwicklungswerkzeuge oder Umgebungen unterstützt wird. Der Begriff CASE wird seit Jahren viel benutzt, allerdings in sehr unterschiedlicher Bedeutung. Hier soll versucht werden, die Gründe dafür zu beleuchten und eine Übersicht über die denkbaren Interpretationen zu geben.

Software Engineering bezeichnet das systematische, methodische und ingenieurmäßige Vorgehen bei der Entwicklung von Software. Die praktische Anwendung der Software Engineering hat zwei Voraussetzungen:

Die Software-Entwickler müssen in den Methoden des Software Engineering ausgebildet sein, und die Methoden müssen in die betriebliche Organisation integriert sein;
es müssen Werkzeuge vorhanden sein, die die Anwendung der Methoden unterstützen, denn fast alle Methoden des Software Engineering sind - zumindest ab einer bestimmten Systemgröße - zu aufwendig, um manuell praktiziert zu werden.

Einführung von CASE

Wir gehen hier nur kurz auf das Ausbildungsproblem ein. Bei Einführung von CASE bei einem Software-Produzenten müssen häufig zunächst einmal die zukünftigen Benutzer der Werkzeuge in den unterstützten Methoden ausgebildet und u.U. die interne betriebliche Organisation der Software Entwicklung verändert werden. Beide Bereiche betrachten wir hier nur als Voraussetzungen für CASE. Es sei aber nicht verschwiegen, daß sie oft das entscheidende Problem bei der Einführung von CASE sind. Neben den eigentlichen Werkzeugen benötigt ein CASE-Anwender daher häufig Beratung bei der Methodenauswahl, Schulungen, Studienmaterialien etc.

Die Auswahl von CASE-Werkzeugen oder -Umgebungen erfordert, genau wie bei anderen Software-Systemen, zunächst eine gründliche Anforderungsanalyse [3], gefolgt von einem Systementwurf. Eine CASE-Umgebung wird normalerweise, ähnlich wie andere Standardsoftware, überwiegend aus im Markt erhältlichen Komponenten bestehen, die an die speziellen Benutzeranforderungen adaptiert bzw. durch eigene Software ergänzt werden. Hieraus resultieren einige Anforderungen an technische Merkmale von CASE-Werkzeugen.

CASE-Werkzeuge und -Umgebungen

Unterstützung bei der Software-Entwicklung durch Werkzeuge war schon immer notwendig. Beispiele konventioneller Werkzeuge sind Text-Editoren, Assembler, Übersetzer, Testhilfen, Modul-Bibliotheken oder andere Werkzeuge mit begrenztem Funktionsumfang. Hinzugekommen sind seit einigen Jahren vor allem Werkzeuge für die frühen Phasen der Software-Entwicklung, z.B. Editoren für Datenflußdiagramme, Entity-Relationship-Diagramme, Petri-Netze und ähnliches. Als CASE-Werkzeug bezeichnen wir hier alle Software-Produkte, die zumindest einzelne bei der Entwicklung von Software benötigte Funktionen anbieten.

Das Arbeiten mit mehreren isolierten Einzelwerkzeugen hat sich allerdings vielfach als zu ineffektiv erwiesen. Dies war ein Hauptmotiv dafür, das „integrierte" Systeme mit einem breiten, „vollständigen" (s.u.) Funktionsumfang zu entwickeln. Letztere bezeichnet man als Software-Entwicklungsumgebungen (SEU) oder CASE-Umgebungen.

Zu unterstützende Tätigkeiten bei der Software-Entwicklung

Bei der Entwicklung eines Softwaresystems werden verschiedene Typen von (meist papierlosen) Dokumenten mit entsprechenden Methoden und Verfahren produziert. Eine Methode ist dabei gegeben durch (1) einen Systembeschreibungstyp, z.B. Petri-Netze, SADT-Diagramme, Quellprogramme usw., (2) eine Menge von detaillierten Verfahren bzw. Arbeitsschritten („Tätigkeiten") und mehr oder minder präzise Regeln, wie die Tätigkeiten auszuführen sind, um die gewünschte Systembeschreibung zu produzieren. Eine Systembeschreibung eines bestimmten Typs beschreibt das Software-System aus einem bestimmten Blickwinkel bzw. auf einem bestimmten Abstraktionsniveau. Um sie mit Werkzeugen verarbeiten zu können, muß sie in der Syntax einer konkreten textuellen oder graphischen Sprache gespeichert werden.

Neben den Tätigkeiten, die unmittelbar zur (Weiter-)-Entwicklung der Software und der dazugehörigen Dokumentation beitragen, treten auch Tätigkeiten zur Projektadministration, Qualitätssicherung, Berichtswesen innerhalb des Unternehmens etc. auf.

In einem Vorgehensmodell (software life cycle) wird mehr oder weniger exakt festgelegt, welche Dokumente zu produzieren, welche Methoden und Verfahren dabei anzuwenden und welche Tätigkeiten in welcher Abfolge durchzuführen sind. Beispiele sind das Wasserfallmodell und das Spiral-Modell [1, 2]. Das Vorgehensmodell hängt vom Typ der Größenordnung und der geforderten Qualität der zu entwickelnden Software sowie anderen Faktoren ab. Die Vorgehensmodelle für verschiedene Klassen von Software können so unterschiedlich sein, daß bestimmte Tätigkeiten bei manchen Vorgehensmodellen auftreten und bei anderen nicht. Beispielsweise wird bei der Methode Jackson Structured Programming (JSP) aus der Beschreibung der Ein-/Ausgabe-Datenstrukturen und ihren Beziehungen zueinander direkt die Feinstruktur des Kontrollflusses abgeleitet. Das Programm ist nicht in Moduln gegliedert. Somit tritt die Tätigkeit „Modulstruktur entwerfen" nicht auf.

Die Methoden in einem Vorgehensmodell sollten integriert sein in dem Sinne, daß die sukzessive zu erstellenden Dokumente semantisch konsistent sind und durch inkrementelle Erweiterung oder durch Transformation auseinander entstehen. Ferner sollten sie keine Teile enthalten, die nicht zum Endergebnis beitragen.

Anforderungen an Software-Entwicklungsumgebungen (SEU)

Vollständigkeit: Eine SEU soll Funktionen enthalten, die alle bei der Entwicklung von Software anfallenden Tätigkeiten unterstützen. Wie schon erwähnt, hängen die anfallenden Tätigkeiten vom Typ der zu entwickelnden Software und vom Vorgehensmodell ab. Gleiches gilt für den Begriff Vollständigkeit. Es ist hier nützlich, zwei Klassen von Tätigkeiten zu unterscheiden:
1. Tätigkeiten, die bei fast allen Vorgehensmodellen auftreten: Projektverwaltung, Entwicklungsprozeßsteuerung, Dokumentation, Textverarbeitung, Berichterstattung, Wiederverwendung von Komponenten (Bibliotheken), elektronische Post und andere Bürotätigkeiten.
2. Vorgehensmodell-spezifische Tätigkeiten, z.B. editieren, prüfen, transformieren, übersetzen etc. von konkreten Systembeschreibungen bzw. Dokumenten.
Alle allgemein auftretenden Tätigkeiten sollen von einer SEU unterstützt werden, ferner alle Entwicklungsmodell-spezifischen Tätigkeiten, die der konkrete Benutzer der SEU ausübt.
Integration: Eine besonders wichtige Anforderung an eine SEU ist, daß sie in mehrfacher Hinsicht integriert ist (wobei sie nur soweit integriert sein kann, wie die unterstützten Methoden integriert sind).
- Verteilung, unterliegendes Betriebssystem: Wenn eine SEU aus einzelnen Werkzeugen zusammengesetzt ist, die ggf. sogar auf verschiedenen Rechnern (PCs, Mainframes, Workstations) laufen, dann müssen als elementarste Form der Integration diese Werkzeuge von einem Arbeitsplatz aus benutzbar gemacht werden.
- Daten: Die verschiedenen Arten von Systembeschreibungen in einem Vorgehensmodell weisen fast immer Redundanzen (oder Konsistenzbedingungen untereinander) auf. Zum Beispiel kann der Datentyp eines Datenflusses in einem Datenflußdiagramm auch als Typ eines Parameters einer Prozedur in einer Modulbeschreibung und als Datentyp in dem zugehörigen Quellprogramm auftreten. Redundante oder ableitbare Daten sollten nicht erneut vom Software-Entwickler eingegeben werden müssen. Wen Redundanzen nicht vermeidbar sind, muß die Beseitigung von Inkonsistenzen unterstützt werden.
- Benutzungsschnittstelle: Um den Lernaufwand zu begrenzen und die Benutzungsfreundlichkeit zu erhöhen, sollen die Sprachen, in denen der Entwickler mit verschiedenen Werkzeugen bzw. Funktionsgruppen der SEU kommuniziert, möglichst einheitlich sein. Dies gilt für alle Abstraktionsebenen der Kommunikation; einzelne Zeichen (lexikalische Ebene), Syntax und Semantik von Kommandos, ganze Dialoge. Die lexikalischen und syntaktischen Aspekte der Kommunikation können durch ein Fenstersystem konstruktiv vereinheitlicht werden.
- (Werkzeug-)Steuerung/Automation: bei den meisten Vorgehensmodellen treten häufig wiederholte Sequenzen von Arbeitsschritten auf (z.B. Editieren - Prüfen - Übersetzen - Binden von Programmen). Entsprechend können durch die Gruppierung von Funktionen innerhalb einer SEU wiederholte Sequenzen von Benutzerkommandos erforderlich sein. Soweit möglich und sinnvoll, sollten Aufruf und Steuerung einzelner Werkzeuge bzw. Funktionen der SEU automatisch erfolgen.
- Überwachung des Software-Entwicklungprozesses: Die Einhaltung der im Vorgehensmodell enthaltenen Regeln sollte kontrolliert werden. Diese Regeln sind immer dann anwendbar, wenn ein Entwickler seinen nächsten Arbeitsschritt auswählt. Die Kontrolle kann z.B. darin bestehen, Abweichungen vom Vorgehensmodell durch Warnungen anzuzeigen, mögliche nächste Arbeitsschritte vorzuschlagen oder die Menge der zulässigen nächsten Arbeitsschritte einzuschränken.
Benutzerfreundlichkeit: Die Bedienung der SEU sollte leicht erlernbar, bequem, konsistent (s. auch Integration der Benutzungsschnittstelle) und an individuelle Benutzerbedürfnisse anpaßbar sein. Die Benutzungsschnittstelle der SEU sollte Software-ergonomische Standards (DIN 66234, Teil 8: Grundsätze der Dialoggestaltung) einhalten und ein Hilfesystem enthalten.
Teamarbeit: Große Software-Systeme werden arbeitsteilig in Teams entwickelt. Die parallele Arbeit der Entwickler und die Kooperation innerhalb des Teams muß unterstützt werden.
Adaptierbarkeit: Die SEU muß an die Arbeitsumgebung und an die organisatorisch/technischen Verhältnisse beim Software-Entwickler (z.B. Layout von Ausdrucken, interne Prozeduren und Standards etc.) adaptierbar sein.
Offenheit: Die Architektur sollte interne Schnittstellen haben, die die Integration mit anderen Werkzeugen (z.B. bei Software-Entwickler bereits vorhanden oder für die Adaptierung zusätzlich benötigten Werkzeugen) erleichtern. Diese Schnittstellen sollten offen sein.

Klassen von Umgebungen

Im folgenden werden einige typische Formen von Umgebungen vorgestellt. Die angegebenen Merkmale beziehen sich sowohl auf den Benutzer sichtbaren Funktionsumfang als auch auf die Architektur der Umgebung. Literaturangaben zu den als Beispiel angeführten Umgebungen finden sich in [4]. Beschreibungen weiterer Umgebungen finden sich in [1].

„Werkzeugkästen" bestehen aus mehreren durch das Betriebssystem verbundenen Einzelwerkzeugen. Die Daten sind in Dateien gespeichert; Werkzeuge tauschen Daten über Dateien aus. Der Benutzer muß die Werkzeuge durch Betriebssystemkommandos aufrufen; allerdings kann durch geeignete Kommandoprozeduren dieser Aufwand stark reduziert und insgesamt der Eindruck einer integrierten Umgebung erweckt werden. Bekanntestes Beispiel ist UNIX mit den zugehörigen Werkzeugen.

Programmierumgebungen unterstützen die „späten" Phasen der Software-Entwicklung („lower CASE"), also Entwurf, Programmierung und Test von Programmen, meist nur in einer konkreten Programmiersprache. Dann nennt man sie auch sprachorientierte Umgebungen. Beispiele sind Interlisp, Smalltalk und Rational für die Sprachen Lisp, Smalltalk bzw. Ada.

Syntax-orientierte Umgebungen beinhalten Sytnax-orientiere Editoren, (inkrementelle) Compiler und andere Werkzeuge, die die Syntax einer oder mehrerer Sprachen, meist Programmiersprachen, kennen und ausnutzen. Die Werkzeuge bzw. die Umgebung werden aus der Grammatik der Sprachen generiert, der Werkzeug-Generator steht oft den Benutzern der Umgebung zur Verfügung, so daß diese eine modifizierte Umgebung generieren können. Beispiele sind der Cornell Program Synthesizer, Gandalf und Mentor.

„Upper-CASE"-Umgebungen enthalten nur Werkzeuge, die die frühen Entwicklungsphasen unterstützen. Typische unterstützte Methoden sind Structured Analysis, SADT, Datenmodellierung mit Entity-Relationship-Diagrammen und JSP: Derartige Umgebungen werden vor allem bei der Entwicklung von administrativer Software auf Basis von Datenbanksystem benutzt; dieser spezielle Anwendungsbereich der Software-Technologie hat vermutlich die meisten Anwender und das umfangreichste Angebot an Werkzeugen, „Upper-CASE"-Umgebungen bzw. Werkzeuge müssen mit einem Data Dictionary System, einem Datenbanksystem und ggf. einer 4.-Generationssprache integriert sein; letztere werden in diesem Kontext meist nicht als CASE-Werkzeuge bezeichnet.

Software-Fabriken sind SEU, die die „industrielle" Software-Entwicklung ermöglichen sollen. Hierzu werden besondere Funktionen in den Bereichen Wiederverwendung und Prozeßkontrolle angeboten. Beispiele sind Arcadia und EUREKA-Software-Factory.

Standardisierung

Ein weiterer Aspekt von CASE ist die Standardisierung: In den letzten Jahren wurden mehrere Vorhaben zur Definition von „CASE-Standards" gestartet. Die Standards sind z.T. nicht auf SEU beschränkt, sondern umfassen allgemeine Software-Entwicklungsumgebungen. Die involvierten Gruppen hielten am Rande der internationalen Workshops CASE 88 und CASE 89 (Imperial College, London) jeweils ein „CASE Standards Coordination Meeting" ab. 1989 waren bereits rund 20 Gruppierungen vertreten. Die wichtigsten Themenbereiche der Standards sind

Methoden,
Datenaustauschformate,
Data Dictionaries,
Benutzungsschittstellen und
verteilte Systeme.

Aus diesen Gruppierungen stammen außerdem mehrere Referenzmodelle für SEU; erwähnenswert ist [5].

Artikelanfang Seitenanfang

Literatur

Balzert, H.: CASE-Systeme und Werkzeuge (Angewandte Informatik ), Mannheim: BI 1990
Boehm, B.: A spiral model of software development and enhancement. IEEE Comput. 21 (5), 61-72 (1988)
Dewal, S., Kelter, U.: Role-based requirements definition for software factories using reusable requirements packages, in: Bennet, K.H. (ed.): Proc. Software Engineering Environments 1989, p. 351-370, University of Durham, Chichester: Horwood 1989
Penedo, L., Riddle, W.E.: Software engineering environment architectures, IEEE Trans. Softw. Eng. 14, 689-696 (1988)
A reference model for frameworks of computer aided software engineering environments. Technical Report TR/55, European Computer Manufacturers Association, 111 Rue du Rhône, CH-1204 Genf (1991)

Artikelanfang Seitenanfang

Autor & Copyright
Prof. Dr. Udo Kelter
FernUniversität Hagen
Fachbereich Mathematik und Informatik
Praktische Informatik V
Postfach 940, 5800 Hagen 1

Artikelanfang Seitenanfang

Java auf Chipkarten

Erläuterung
Literatur
Autor & Copyright

Erläuterung

Java-Technologie dringt derzeit in immer mehr Bereiche vor: Javafähige Web-Browser sind inzwischen eine Selbstverständlichkeit geworden, und auch die Aussicht, daß 1998 die ersten Telefone mit Java-Unterstützung auf den Markt kommen werden, erregt heute kaum noch Aufsehen.

Selbst für manche Java-Insider überraschend ist jedoch die Entwicklung im Bereich Javafähiger Chipkarten: Ende Oktober 1996 wurde von JavaSoft (mit technischen Beiträgen von Schlumberger) das sogenannte JavaCard API V1.0 publiziert und im Mai 1997 war der erste Prototyp einer Javafähigen Chipkarte verfügbar (siehe http://www.cryptoflex.com/SiteGuide/SmartCardWebSites/smartcardwebsites.html). In der Zwischenzeit arbeitet JavaSoft zusammen mit verschiedenen Technologiepartnern unter anderem dem JavaCard Forum (www.javacardforum.org) an einer Version 2 dieser Spezifikation.

Es stellt sich die Frage, was hinter dieser Technologie steckt und was von ihr zu erwarten ist.

Aufbau einer Java-Chipkarte

Zunächst ist eine Chipkarte keine Laufzeitplattform für Java-Applets; dies macht aus verschiedenen Gründen keinen Sinn, u.a. weil die E/A-Schnittstelle einer Chipkarte sehr schmalbandig (9600 Kb/s) ist, und das jeweilige Laden eines Applets vor dessen Nutzung zu lange dauern würde. Statt dessen arbeitet eine JavaCard mit persistenten Java-Anwendungen.

Die dafür notwendige Java-Laufzeitplattform („Virtual Machine" VM) läßt sich in einer Chipkarte entweder in Form von Software oder als Hardware realisieren. Letzteres z.B. durch Integration des Chip-Layouts „Pico-Java" von Sun Microsystems. Eine solche Hardwareimplementierung verspricht gegenüber einer Softwareemulation eine höhere Verarbeitungsgeschwindigkeit, die Realisierung ist aber aufwendiger und dürfte frühestens Ende 1998 zu erwarten sein.

Die zur Zeit verfügbare JavaCard [1] „Cyberflex" der Firma Schlumberger ist eine Softwarelösung. Der prinzipielle Aufbau einer solchen Karte ist in Abb. 1 dargestellt: Grundlage ist ein handelsüblicher 8-bit Chipkartenprozessor (basierend auf Intel 8051 oder Motorola 6805) mit einem Betriebssystem nach ISO-7816. Darauf ist eine JavaCard VM implementiert, die die Java-Anwendungen (sog.„Cardlets") interpretiert und das JavaCard API, u.a. für den Zugriff auf die in ISO 7816-4 spezifizierten Dienste, zur Verfügung stellt.

Abb. 1 Aufbau einer JavaCard

Der Speicherplatz in einer Chipkarte ist sehr beschränkt: im Falle von Cyberflex benötigt das Betriebssystem ca. 8 Kb, der Java-Interpreter 4 KB, das API 1.6 KB Bei der heutigen Technologie stehen dann noch etwa 2.8 KB im EEPROM für Cardlets zur Verfügung, die sich mit ca. 200 Byte RAM begnügen müssen.

Die derzeitige sowie auch die geplante Version 2 der JavaCard Spezifikation unterstützt nicht den vollen Sprachumfang von Java, sondern stellt lediglich eine Untermenge zur Verfügung. Es gibt u.a. keine 32-bit Ganzzahlarithmetik, keine Gleitkommaarithmetik, keine dynamische Speicherverwaltung, keine Ausnahmebehandlung und keine nebenläufigen Routinen (Threads) [2, 3].

Wozu Java in einer Chipkarte?

Die Möglichkeit, Java-Programme in einer Chipkarte ablaufen zu lassen, ist sicher spektakulär, aber welche tatsächlichen Vorteile bietet ein solches Szenario? Diese Frage stellt sich insbesondere, da Java hier nicht als „downloadable content" (Java-Applets) eingesetzt wird, sondern lediglich als Programmiersprache für die Chipkarte dient.

Eine der wichtigsten Kundenforderungen ist die Möglichkeit, Anwendungen auf einer Chipkarte auch nach ihrer Initialisierung bzw. Personalisierung leicht austauschen oder neu installieren zu können. Dies ist aus zwei Gesichtspunkten heraus interessant: Zum einen vereinfacht es die Realisierung von Kartenanwendungen erheblich, da das Einbringen der Software in die Karte nicht mehr mit dem Kartenbetriebssystemhersteller beim Erzeugen der ROM-Maske koordiniert werden muß. Dies war bisher oft notwendig, da aus Platzmangel das Betriebssystem der Karte auf die Anwendung zugeschnitten werden mußte. Java verspricht nun, durch eine klare Trennung zwischen Anwendungs- und Betriebssystemprogrammierung, wesentlich schneller und flexibler am Markt reagieren zu können. Eine weitere Anforderung ist es, Updates der Software auf ausgegebenen Karten durchzuführen oder auch eine Karte an neue Anwendungsbereiche anzupassen. Mit der derzeit gängigen Technologie ist die Veränderung der Kartensoftware bei einmal ausgegebenen Karten nur noch sehr schwer möglich und setzt genaue Kenntnisse des Kartenbetriebssytems voraus.

Die Verwendung von Java weist daher gegenüber der gängigen Technologie zwei entscheidende Vorteile auf:

Plattformunabhängigkeit: Cardlets sind nicht an bestimmte Chipkarten gebunden, sondern können in jeder Javafähigen Chipkarte (unabhängig vom Kartenbetriebssystemhersteller und dem zugrundeliegenden Prozessor) genutzt werden.
Im Vergleich zur herkömmlichen Chipkartenprogrammierung bietet Java Garantien für erhöhte Sicherheit wie im folgenden Abschnitt kurz beschrieben werden soll.

Sicherheitsaspekte

Sicherheit spielt bei Chipkarten eine wesentliche Rolle, denn eine Chipkarte enthält oft hochsensible Informationen (z.B. geheime Schlüssel), die nicht nach außen gelangen dürfen oder eine elektronische Geldbörse, bei der sich der Inhalt nicht auf unkontrollierte Weise verändern sollte. Wird nun bei einer Java-Chipkarte eine neue Anwendung in das Innere der Karte geladen, so muß sichergestellt werden, daß diese Anwendung nur mit ihren eigenen Daten arbeitet und Daten bzw. Programmkode anderer Anwendungen weder lesen, verändern noch löschen kann.

Das Sicherheitsmodell von Java spielt dabei eine wesentliche Rolle, denn es verhindert den direkten Zugriff auf Information außerhalb der durch die virtuelle Maschine definierten Grenzen (Sandbox). Dies kann jedoch nur dann garantiert werden, wenn die Implementierung der Java-VM fehlerfrei ist. Arbeiten, die in diese Richtung zielen, stehen jedoch erst in den Anfängen (siehe [4], www.cli.com/software/djvm/).

Wenn unterschiedliche Anwendungen miteinander Daten austauschen sollen, so soll dies durch das JavaCard API in kontrollierter Weise gewährleistet werden. Dabei stellt man sich bei Karten, die z.B. im Finanzbereich eingesetzt werden sollen, vor, daß die Cardlets mit einer digitalen Signatur versehen werden. Bei der Instantiierung auf der Karte könnte dann zum einen die Integrität der Anwendung überprüft werden und zum anderen ließen sich aus der Unterschrift gewisse Zugriffsrechte für das Cardlet ableiten. Über ähnliche Mechanismen („Secure Messaging") ließe sich auch das eigentliche Laden von Cardlets nur auf den Kartenherausgeber beschränken.

Danksagung: Wir danken Herrn Dr. Frank Schäfer-Lorinser (Deutsche Telekom, TZ Darmstadt) für nützliche Anregungen.

Artikelanfang Seitenanfang

Literatur

Guthry, S.: Java Card: Internet Computing on a Smart Card. IEEE Internet Computing, Vol. 1, No. 1, pp. 57–59, 1997.
Sun Microsystems: Java Card 2.0 Language Subset and Virtual Machine Specification. 1997.
http://java.sun.com/products/javacard/index.html
Sun Microsystems: Java Card 2.0 Application Programming Internfaces. 1997. http://java.sun.com/products/javacard/index.html
Cohen, R. M.: The defensive Java Virtual Machne Specification, Technical report, draft Release, Computational Logic Inc., Austin, TX, 1997.
www.cli.com/software/djvm/html-0.5/djvm-report.html

Artikelanfang Seitenanfang

Autor & Copyright
Matthias Kaiserswerth¹, Joachim Posegga²
¹IBM Zürich Research Laboratory,
Säumerstr.4,
CH-8803 Rüschlikon,
kai@zurich.ibm.com
²Deutsche Telekom AG,
Technologiezentum,
D-64276 Darmstadt
posegga@tzd.telekom.de

Artikelanfang Seitenanfang

Content Management

Kurzinfo
Erläuterung
Literatur
Autor & Copyright

Kurzinfo Viele Content-Management-Systeme (CMS) sind aus bestehenden Anwendungen hervorgegangen und lassen noch heute den Branchen- oder Technologiefokus ihrer Urheber erkennen (wie z.B. Dokumentenmanagementsysteme, Redaktionssysteme, Workflow-Management-Systeme, Datenbankmanagementsysteme u.a.). Damit sind nicht alle Systeme, die den Namen CMS tragen, miteinander vergleichbar oder für einen Anwendungsfall beliebig einsetzbar.

Erläuterung

Mit Content wird oft der Inhalt bezeichnet, der sich dem Betrachter auf einem Informationsträger optisch präsentiert.

Im Zusammenhang mit CMS muss der Begriff „Content" präzisiert werden. Ein innovatives CMS behandelt Content als Summe von wesentlichen Einzelinformationen. Diese sind Struktur, Darstellungsform und Inhalt (Abb. 1). Besonders dann, wenn Informationen nicht nur für das menschliche Auge bestimmt sind, sondern auch zur automatisierten Weiterverarbeitung (single source multiple media, d.h. einmal erstellen, aber mehrfach und auf verschiedenen Medien publizieren) oder Weiterverwendung (syndication) eingesetzt werden, führt dies zwangsläufig zu einer Zerlegung und separaten Datenhaltung dieser drei wesentlichen Bestandteile.

Abb. 1. Was ist Contentorientierung?

In allen Dokumenten bzw. Informationsträgern ist diese Dreiteilung enthalten; man kann auch von der Anatomie der Dokumente bzw. Informationen sprechen. Oft lässt sich die Anatomie der repräsentativen Ausprägung einer Information nur mit dem Auge des Betrachters analysieren. Die datentechnische Ausprägung lässt diese Abstraktion für eine Maschine oft nicht zu, da Inhalt und formale Layoutanweisungen vermischt wurden.

Die Anatomie von Dokumenten ergibt sich aus Informationen nach folgendem Muster:

Struktur, eine inhaltliche Definition der Einzelinformationen und ihrer Abfolge bzw. Verschachtelung.
Beispiel: Eine Presseinformation kann aus Titel, Kurzzusammenfassung, Detailinformation, Ansprechpartner und Datum bestehen. Der Ansprechpartner ist wiederum eine übergeordnete Struktur von Elementen, die den Vornamen, Nachnamen, Telefonnummer und E-Mail-Adresse beschreiben.
Darstellung, eine formale Beschreibung zur Repräsentation auf einem möglichen Ausgabemedium. Stylesheets enthalten informationstechnische Anweisungen, wie der Inhalt formatiert und positioniert werden soll.
Beispiel: Damit eine Presseinformation per Post verschickt werden kann, muss sie auf Papier ausgedruckt werden.
Dafür wird der Inhalt im Layout so angeordnet, dass er eine DIN-A4-Seite optimal und der Corporate Identity des Unternehmens entsprechend ausfüllt. Dieselbe Presseinformation soll in ähnlicher Weise auf dem Webserver veröffentlicht werden. Dazu wird ein weiteres Stylesheet auf den Inhalt der Presseinformation angewandt, um dieselben Inhalte gemäß dem Web Styleguide zu präsentieren. Dieses Verfahren kann für beliebige Ausgabemedien angewandt werden, so dass der Inhalt jedes Mal unverändert bleibt und nur durch Stylesheets dem Ausgabemedium angepasst wird (single source multiple media).
Inhalt, der entsprechend der Strukturdefinition in Datenelementen abgebildet wird. Dabei ist die Datenhaltung des Inhalts von besonderer Bedeutung, denn die Metainformation muss erhalten bleiben.
Beispiel: In der Presseinformation steht in der Strukturdefinition ein Inhaltselement mit der Bezeichnung „Titel". Der Inhalt dieses Elements beschreibt die Schlagzeile einer Pressemeldung. Datentechnisch muss der Inhalt mit der Metainformation „Titel" fest verbunden bleiben. Damit ermöglicht sich die automatisierte Erstellung von Verzeichnissen und Übersichtsseiten, die alle Schlagzeilen und Kurzzusammenfassungen von Presseinformationen darstellen.

CMS, die Daten entsprechend dieser Dreiteilung behandeln, verfügen über vielfältige Möglichkeiten zur weiteren clientseitigen und automatisierten Datenverarbeitung. Die Trennung von inhaltlichen und formalen Daten und der Einsatz von Stylesheets bieten neben der Darstellung von Informationen auf unterschiedliche Ausgabemedien einen weiteren wichtigen Vorteil: Die Informationen können benutzer- und bedarfsgerecht aufbereitet werden. Durch geeignete Benutzerprofile können die personen- und prozessrelevanten Sichten auf Informationen realisiert werden.

Durch den Dezentralisierungsgedanken ist grundsätzlich, aufgrund geringerer Durchlaufzeiten (time to action), eine höhere Aktualität gewährleistet. Die durchgängige elektronische Kommunikation reduziert sowohl Medienbrüche als auch die daraus resultierenden Folgefehler. Der klassische Informationsfluss entlang der Prozessketten führt auch im digitalen Zeitalter immer noch viel zu oft über Papier und Hauspostverteiler.

Die Kernprozesse und Funktionen, die von einem CMS unterstützt werden müssen, umfassen

Benutzerverwaltung (Gruppen, Rollen, Rechte),
Entwicklung der Sitestruktur, Navigationshilfen und Stylesheets bzw. Templates für Redakteure,
Erstellung (Authoring neuer redaktioneller Informationen),
Pflege (Editing von bestehenden Informationen),
Qualitätssicherung und Freigabe (Workflow zwischen den einzelnen Berechtigungsgruppen),
Steuerung (Release- und Verfallsdatenüberwachung (inkl. Versionierung und evtl. Archivierung), Stylesheetverwaltung und Merging, Scheduling für Tasks wie z.B. zyklischer FTP-Export).

Zur Unterstützung dieser Prozesse bieten CMS wesentliche Systemfunktionen, die den Prozesseigner bei Routinetätigkeiten unterstützen und korrelierende Aufgaben automatisiert im Hintergrund ablaufen lassen können (z.B. das gleichzeitige Löschen von Verlinkungen, wenn eine Quelle entfernt wird).

Folgende Systemfunktionen bilden charakteristische Merkmale eines innovativen CMS: Trennung von Struktur, Darstellung und Rohinhalten, Verwaltung von Struktur- und Darstellungsinformationen, dynamische Einbindung von Rohinhalten in die Darstellungsvorlagen (Stylesheets) für unterschiedliche Ausgabemedien, Benutzerprofile und Konformität zur Corporate Identity, Unterstützung bei redaktioneller Neuerstellung durch standardisierte und webbasierte Templates, Automatisierung der Pflege, Sicherung, Konsistenz und Aktualität von Informationen (Linküberprüfung), Abbildung und Unterstützung des Workflow im Rahmen des Content-Lifecycle sowie Zugangskontrolle über Benutzer-, Rollen- und Rechteverwaltung.

Systeme – Architektur und Technik

Content-Management-Systeme besitzen unterschiedliche Ausprägungen in der Architektur und in den eingesetzten Technologien. Die wesentlichen

Faktoren sind zum einen die technologische und anwendungsspezifische Historie der Systeme (z.B. Workflow- und Dokumentenorientierung) und zum anderen das angestrebte Einsatzszenario (z.B. Web-CMS). Wesentliche Komponente einer CMS-Architektur ist ein Systemkern zur Verwaltung von Inhalt, Strukturinformationen und Stylesheets. Darüber hinaus verfügen CMS-Architekturen über eine Komponente zum Publizieren des Contents. Neben dem Systemkern stehen Werkzeuge zur Erstellung und Verwaltung von Content zur Verfügung.

Im Bereich der Datenhaltung kommen bei CMS unterschiedliche Technologien zum Einsatz: von der dateiorientierten, indexsequentiellen und relationalen Datenhaltung bis hin zu OO-Datenbanken. Zum Teil werden eigenentwickelte Datenbanken oder Datenbankerweiterungen eingesetzt, um die Trennung von Inhalt, Struktur und Layout abzubilden. Ein hohes Potenzial, speziell für XML-basierte CMS, bietet der Einsatz von OO-Datenbanken, da hier eine direkte, verlustfreie und wiederherstellbare Datenhaltung möglich ist.

Die Anforderungen an ein Betriebssystem auf Clientseite sind überwiegend durch einen PC oder einen Browser gegeben. Für den Server bzw. das CMS kommen weitgehend UNIX- und Windows-NT-Umgebungen zum Einsatz. Vor allem CMS mit hohen Volumina und hohem Anspruch an Performance greifen auf UNIX-basierte Betriebssysteme zu. Ein Teil der betrachteten CMS wird auch exklusiv auf Windows NT oder UNIX angeboten.

Die betrachtete Software ist weit gestreut und basiert auf eigenentwickelten Programmier- und Scriptsprachen oder herstellerspezifischen Standards, z.B. Lotus Notes, ASP, ColdFusion. Daneben finden sich CMS, die vollständig in der plattformunabhängigen Programmiersprache JAVA implementiert sind. Ein wesentlicher Trend liegt in dem Einsatz von JAVA als Implementierungssprache und -umgebung und XML als Beschreibungs- und Kommunikationsstandard.

Taxonomie

Aufgrund der unterschiedlichen Ausrichtungen und Technologien lassen sich keine typischen CMS erkennen. Eine anwendungsorientierte Klassifikation von webbasierten CMS ist nach dem Prinzip der Informationsaktualisierung und des Publishing möglich.

Abb. 2. Staging-CMS

Staging-Server

Er ist für die Darstellung statischer Informationen geeignet, die zyklisch geändert werden müssen. Bei dieser Art von CMS werden die Inhalte auf einem eigenen Server erstellt und verwaltet. Zu einem definierten Zeitpunkt wird ein Generat aus statischen HTML-Seiten erzeugt (Staging) und auf einen Webserver exportiert (Abb. 2).

Abb. 3. Dynamisches CMS

LIVE-Server

Dieser ist für Informationen geeignet, die dynamisch erstellt oder geändert werden müssen (Abb. 3). Die Informationen sind durch Kurzlebigkeit und schnell abfolgende Aktualisierungszyklen gekennzeichnet (z.B. laufende redaktionelle Nachrichtenmeldungen, Kursverlauf von Wertpapieren).

Artikelanfang Seitenanfang

Literatur

Altenhofen, C.: XML – Informationsstrukturierung in Internet und Intranet. In: Computerworld Schweiz 41, 7–12 (11.10.1999)
Bullinger, H.-J. (Hrsg.), Schuster, E., Wilhelm, S.: Content Management Systeme: Auswahlstrategien, Architektur und Produkte. Düsseldorf: Verlagsgruppe Handelsblatt, Wirtschaftswoche, 2000
Gersdorf, R.: Prozessorientiertes Content-Management: Entwicklungstendenzen im Dokumentenmanagement. Wirtschaftswissenschaftliches Studium 29(9), 523–527 (2000)
Karajannis, A., Bissel, T.: Website-Verwaltung: Content-Management-Systeme im Vergleich. iX 11, 66–75 (2000)

Artikelanfang Seitenanfang

Autor & Copyright
Erwin Schuster, Stephan Wilhelm
Fraunhofer-Institut für Arbeitswirtschaft und Organisation,
Nobelstraße 12,
D-70569 Stuttgart
erwin.schuster@iao.fhg.de
stephan.wilhelm@iao.fhg.de

Artikelanfang Seitenanfang