Abb. 1 Aufbau einer JavaCard
Informatik-Lexikon
C
CASE
Chipkarten, Java auf
Content Management
CASE - Computer Aided Software Engineering |
ErläuterungCase 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:
Einführung von CASEWir 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 -UmgebungenUnterstü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-EntwicklungBei 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)
Klassen von UmgebungenIm 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. StandardisierungEin 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
Aus diesen Gruppierungen stammen außerdem mehrere Referenzmodelle für SEU; erwähnenswert ist [5]. |
Java auf Chipkarten
|
ErläuterungJava-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-ChipkarteZunä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. |
|
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:
SicherheitsaspekteSicherheit 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. |
|
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:
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
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 TechnikContent-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. TaxonomieAufgrund 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-ServerEr 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-ServerDieser 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). |
|