Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Migration von Smalltalk nach Java - L sungsm glichkeiten und

VIEWS: 46 PAGES: 9

									Tom Krauß

Migration von Smalltalk nach Java Lösungsmöglichkeiten und praktischer Nutzen
1 Einleitung
In unser sich schnell verändernden EDV-Welt sind viele (längerfristige) IT-Projekte schon heute überholt, noch bevor sie in Produktion gehen. Die Gründe liegen neben der schnellen Änderung von Geschäftsprozessen auch in einem raschen Wandel der Entwicklungs-Werkzeuge und Architekturen. Gestern noch C++ bzw. Smalltalk und Client-/Server-Computing, heute Java und Network-Computing sind die Schlagworte, die diesen Wandel symbolisieren. Gründe für eine Umstellung auf neue Werkzeuge und Architekturen gibt es reichlich: der technische Fortschritt verspricht neue Möglichkeiten, die Unterstützung für „Legacy-Werkzeuge“ durch den Hersteller ist nicht mehr in ausreichendem Maße gegeben, und die Motivation der Software-Entwickler kann durch neue Betätigungsfelder verbessert werden. Ein Versprechen der Objektorientierung ist die Flexibilität der erstellten Bausteine. Tatsächlich kann bei entsprechenden Voraussetzungen diese Flexibilität genutzt werden, um eine Legacy-OO-Anwendung auf neue Gegebenheiten einzustellen. Kosten, Nutzen und Risiko müssen bei einer Migration abgewogen werden – der organisatorische Prozeß zur Ablösung einer Alt-Anwendung muß gut durchdacht sein. Das Thema Migration in Richtung Java ist im Zuge des heute schon fast vollzogenen Wandels zum Network-Computing-Paradigma besonders aktuell. Der Vortrag wird Migrationsstrategien unter technischen, organisatorischen und wirtschaftlichen Aspekten vorstellen. Ausgehend von den Anforderungen an ein Werkzeug für eine Smalltalk nach Java-Migration wird ein Verfahren zur Implementierung solch eines Werkzeugs vorgestellt.

2 Gründe für eine Migration
Gründe für eine Migration sind mannigfaltig und werden individuell unterschiedlich bewertet werden. Der Auslöser scheint oft das sinkende Vertrauen gegenüber dem Hersteller einer Legacy-Entwicklungsumgebung zu sein. Man traut diesem nicht mehr zu, eine langfristige Weiterentwicklung des Produkts gewährleisten zu können bzw. zu wollen. Dieser Grund alleine wird jedoch selten eine umfangreiche Migration rechtfertigen. Die Altanwendung wird oft unverzichtbarer Bestandteil der IT eines Unternehmens sein, von ihrem Funktionieren werden wichtige Prozesse im Unternehmen abhängen. Ein Austausch scheint mit enormen Risiken und Kosten verbunden zu sein. Der Leidensdruck für die Unternehmen verstärkt sich jedoch dann, wenn offenbar wird, daß mit einer „Alt-Technologie“ neue Möglichkeiten, die enorme Wett-

bewerbsvorteile der Unternehmen bedeuten würden, nicht oder nur schwierig realisiert werden können. Konkret finden sich diese Gründe aktuell für viele Smalltalk-Projekte wieder. Als neue Technologie hat sich Java etabliert. Java-basierte Anwendungen versprechen mit den Schlagworten „Thin-Client-Ansatz“, „Internet-enabled“ und „Zero Adminstration“ neue technische Möglichkeiten und reduzierte Kosten und Wettbewerbsvorteile durch die direkte Erreichbarkeit von End-Kunden über das Internet. All dies scheint in Smalltalk-Lösungen nicht realisierbar zu sein, da die hierfür notwendigen Produkterweiterungen der Smalltalk-Werkzeuge nicht in ausreichendem Maße stattfinden. Das Thema „Migration“ wird aus diesem aktuellen Anlaß im Folgenden am konkreten Fallbeispiel Smalltalk nach Java – Migration behandelt.

3 Anforderungen an eine Migration
Welche Erwartungen werden mit dem Thema Migration verknüpft?  Architekturelle Weiterentwicklung: Die reine Migration bringt nur einen beschränkten Nutzen. Parallel mit der Umstellung muß die Applikation sich architektonisch weiterentwickeln, um neue Möglichkeiten zu öffnen. Finanzielle Machbarkeit: Das Budget für eine Migration sollte natürlich wesentlich unterhalb des Budgets liegen, das für eine Neu-Entwicklung veranschlagt werden muß. Diese Anforderung kann nur erfüllt werden, wenn Werkzeuge für die Umstellung eingesetzt werden. Beim Einsatz von Werkzeugen ergeben sich eine ganze Reihe von Folgeanforderungen. Wartbarkeit: Der entstehende Source-Code muß wartbar sein. Er soll im Idealfall nicht von einer handgeschriebenen Implementierung unterschieden werden können. Dazu gehört, daß Syle-Guide-Konformität mit den Style-Guides der Zielplattform besteht und die Besonderheiten der Quellplattform nicht mehr erkennbar sind. Integration mit den Produkten der Zielplattform: Ideal ist, wenn das Resultat der Migration mit Entwicklungswerkzeugen für das Zielsystem bearbeitet werden kann und „Standard-Komponenten“ der Zielplattform Berücksichtigung finden. Es wird beispielsweise wenig Sinn machen, ein Projekt auf Basis einer für Java umgeschriebenen Bibliothek von Smalltalk-Kernklassen zu warten. Die Integrationsfähigkeit mit neuen Java-Komponenten, die im Rahmen des Projekts Verwendung finden sollen, wäre eingeschränkt und der zusätzliche Wartungsaufwand für die Pflege der umgeschriebenen Kernbibliotheken wäre nicht vertretbar. Parallele Versionsverwaltung: In der Übergangszeit der Umstellung muß mit einer parallelen weitergehenden Wartung des umzustellenden Projekts ausgegangen werden. Das Migrations-Verfahren sollte deshalb erlauben, alle inkrementellen Updates in der Quelle auf die Zielplattform applizieren zu können.









3.1 Umfang der Migration Eine Migration muß nicht eine Komplettumstellung einer Alt-Anwendung bedeuten. Vor allem, wenn nicht der Untergang des Herstellers die treibende Kraft für die Migrationsentscheidung ist, kann eine Teil-Migration der Applikation z.B. der

Präsentations-Schicht alleine, wesentliche Vorteile der Verwendung von JavaTechnologien ermöglichen.

Vorteile dieser „Kooperationslösung“ sind ein weitergehender Re-Use der bestehenden Fachklassen. Randbedinung für diese Vorgehensweise ist, daß ein geeigneter Mechanismus zur Kopplung des Java-Klienten und des Smalltalk-Servers vorhanden ist (etwa eine CORBA-Schnittstelle) und daß die Architektur der Anwendung die Umstellung in Richtung Applikations-Server mit den damit verbundenen Voraussetzungen, z.B. Multi-Threading, mit vertretbaren Aufwänden ermöglicht.

4 Migrationserfahrungen
GEBIT besitzt einen breiten Smalltalk-Kundenstamm. Ein Großteil der Projekte im Smalltalk-Bereich stützt sich auf ein speziell entwickeltes Smalltalk-BusinessFramework. Dieses forciert insbesondere ein einheitliches Entwicklungsmodell und schafft die Voraussetzungen für eine projektübergreifend wiederverwendbare Klassenbibliothek von Geschäftsklassen. Ein Fachobjekt kennt dabei insbesondere seine Attribute, seine Relationen zu anderen Fachobjekten und eine Anzahl von Services. Aufsetzend auf dieses Framework sind bereits hunderte von Fachklassen entstanden. Auch bei der Java-Projekt-Entwicklung wird bei GEBIT nun auf ein Business-Framework gesetzt. Aufgrund der neuen technologischen Gegebenheiten wurde das Modell für die Fachobjekte im Java-Framework wesentlich erweitert:   Ein Java-BO ist konfigurierbar – je nach Lokation, wo das Objekt eingesetzt wird Die Services eines Java-BOs werden mit Hilfe von Java-Interfaces beschrieben

Eine Umstellung der Fachklassen von Smalltalk nach Java per Hand hätte bedeutet, daß hunderte von Klassen neu geschrieben werden müßten. Da bedingt durch die Modell-Änderung einer Smalltalk-Klasse nun mehrere Java-Klassen entsprechen, hätte sich die Anzahl der von Hand zu schreibenden Klassen vervielfacht.

Da durch den Einsatz eines Werkzeugs bei größerem Projektumfang selbst bei einer geringeren Prozentzahl von konvertierbaren Klassen eine erhebliche Arbeitsersparnis zu erwarten war, wurde von GEBIT ein Werkzeug für die Migration entwickelt. „S2J“ unterstützt die Migration von ObjectStudio-Smalltalk-Anwendungen nach Java. Dieses Werkzeug und der in ihm realisierte Lösungsansatz wird im Folgenden vorgestellt. Die einheitliche Struktur der Fachobjekte, vorgegeben durch das BusinessFramework, machten eine Konvertierung besonders einfach. Mit S2J war es möglich, etwa 80% der Implementierungen der Fachobjekte automatisiert zu konvertieren. Lediglich ein kleiner Teil der konvertierten Services mußte von Hand nachbearbeitet werden.

5 Die wichtigsten Unterschiede von Smalltalk und Java
Zum besseren Verständnis der technischen Funktionsweise des Werkzeugs sollen im Folgenden Unterschiede und Gemeinsamkeiten von Smalltalk und Java beleuchtet werden. 5.1 Die Programmiersprache Die Grammatik der beiden Sprachen ist sehr unterschiedlich. Smalltalk besitzt, wie der Name treffend schon nahe legt, eine sehr einfache Grammatik. Kontrollstrukturen werden auf Methoden abgebildet, die komplexere Grammatik von Java zeigt sich auch in der Tatsache, daß Java 57 Keywords und weitere reservierte Wörter besitzt. Zum Vergleich: in der Smalltalk-Syntax sind 7 Schlüsselworte definiert. Die Philosophien beider Programmiersprachen sind recht unterschiedlich. Während Java dem Programmierer syntaktische Mittel zur Deklaration von Typen und Zugriffskontrolle zur Verfügung stellt und den Anspruch hat, mit Hilfe des Compilers bereits grundlegende Programmierfehler zu erkennen, geht Smalltalk den Weg mit Hilfe weniger, flexibler Sprachkonstrukte einen übersichtlichen und damit gut wartbaren Programmcode zu forcieren. Diese Tatsache wird recht eindrucksvoll durch Messungen, die einen bis zu 7 mal längeren, vergleichbaren Java Programmtext ergeben, belegt. Beide Sprachen haben den Anspruch voll objekt-orientiert zu sein. Java weicht von diesem Anspruch jedoch in einigen Bereichen ab. So existieren bei Java immer noch Primitiv-Typen – ein Relikt aus der C-Welt – und in Java existiert kein Metamodell: Methoden können nur statisch an eine Klasse gebunden werden und Objekte werden nicht durch einen Methodenaufruf, sondern einen Konstruktor erzeugt. Ein wichtiges in Java nicht explizit vorhandenes Sprachelement bei Smalltalk sind Blöcke, die recht intensiv von Smalltalk-Programmierern genutzt werden. Java führte mit der Version 1.1 Inner-Classes ein, die es ebenfalls ermöglichen, Callbacks zu implementieren. Zum Schluß gibt es noch einige Schmankerl in der Smalltalk-Sprache wie die dynamische Erweiterung von Klassen, das „become:“-Feature und das Vorhandensein einer zentralen doesNotUnderstand:-Methode, die ihresgleichen in Java suchen und deren exzessive Verwendung eine Konvertierung unmöglich machen würden. Da diese Elemente in typischen Geschäftsanwendungen nicht all zu oft auftauchen, spielen sie im Kontext dieses Aufsatzes eine untergeordnete Rolle.

5.2 Klassenbibliotheken In Struktur und Funktionalität der Basisklassen wie Object und Collection unterscheiden sich Smalltalk und Java erheblich. Eine 1 :1 –Sprachkonvertierung müßte versuchen, die gesamte Klassenhierarchie Smalltalks mit zu konvertieren. Da Java ein Konzept für Namespaces anbietet, würde dieser Ansatz nicht einmal zu Namenskonflikten führen und wäre theoretisch denkbar. Spätestens die sogenannten Primitiven, die Black-Boxes einer jeden Smalltalk VM, können jedoch gar nicht konvertiert werden. Außerdem würde dieser Ansatz zu einem Resultat führen, das sich nicht in die Java-Welt einfügt und dort nicht sinnvoll weiter gewartet werden kann. Anzustreben ist ein Ansatz, der in möglichst breitem Umfang vorhandene StandardJava-Klassenbibliotheken verwendet. Obwohl eine Erweiterung der Kernklassen wenn möglich zu vermeiden ist, kann es notwendig sein, entsprechende Erweiterungen in den durch Java vorgegebenen Core-Klassen zu erstellen, wenn eine Funktionalität in den Core-Klassen gar nicht implementiert ist. So enthalten die in Java 1.2 definierten Collection-Klassen zum Beispiel keine Klasse Bag. 5.3 Style-Guides Style-Guides enthalten gängige Muster für einen effizienten Einsatz einer Programmiersprache und sind für eine professionelle Arbeit unverzichtbar. Im Smalltalk-Bereich gibt es einige wenige zum Beispiel in [Skublics + KT 96] definierte Muster, die breite Verwendung gefunden haben. In der Java-Welt gibt es Style Guides unterschiedlichen Ursprungs mit sehr unterschiedlichen Philosophien. Folgende Liste kann als Referenz für namhafte Beispiele dienen:    Java Code Conventions from Netscape [Badeaux 97] Java Code Conventions from Sun [Sun 97] Java Development Standards [Fussell 98]

Ein Konvertierungswerkzeug muß konfigurierbar sein, um die erzielten Resultate mit einem zu verwendenden Style-Guide abstimmbar zu machen. 5.4 Werkzeuge Insbesondere zur Erstellung von Benutzeroberflächen werden häufig Werkzeuge eingesetzt. Diese Werkzeuge nutzen recht unterschiedliche Verfahren bei der Generierung von Quellcode. Deshalb ist sogar im Java-Bereich, wo ein einheitliches Komponenten-Modell (JavaBeans) existiert, die visuelle Bearbeitung von JavaKomponenten nicht zwischen Werkzeugen portabel. Der Übersetzungsprozeß sollte dennoch den Quellcode so erzeugen können, daß in der Zielumgebung die migrierten Komponenten (meistens GUI-Oberflächen-Klasssen) visuell bearbeitet werden können.

6 Migrationsverfahren
Auf dem Internet sind einige Ansätze zur Konvertierung von Smalltalk nach Java publiziert. Nachteil der meisten Ansätze ist, daß in ihnen das Grundprinzip „Erzeugung wartbarer Java-Awendungen“ nicht berücksichtigt wird. Der interessierte Leser sei hier exemplarisch auf die Artikel

 

Translating Smalltalk to Java, [Bothner 96] SmallJava, [Fussell 97]

verwiesen. Die folgenden Schritte beschreiben den Algorithmus einer Konvertierung, wie sie vom Migrationswerkzeug S2J durchgeführt wird. Die Grundidee des S2J-Konvertierungsvorgangs ist dabei die regelgesteuerte Transformation eines syntaktischen Baums gemäß einer Quellgrammatik in einen syntaktischen Baum für eine Zielgrammatik. Um diese Transformation durchführen zu können, sind aufgrund einiger fehlender Elemente in der Grammatik der Sprache Smalltalk (zum Beispiel die Typ-Information) jedoch einige Analysen notwendig, die diese Elemente bestimmen. 1. Erzeugung des syntaktischen Baums des Quellcodes 2. Typen-Analyse 3. Regelgesteuerte Transformation der Knoten des Quellbaums auf einen Zielbaum 4. Code-Generierung ausgehend vom Zielbaum Die genaue Erklärung jeder dieser Schritte würde natürlich den Rahmen jedes Aufsatzes sprengen. Hier sollen exemplarisch ein paar Verfeinerungen vorgestellt werden. 6.1 Die Erzeugung des Quell-Grammatik-Baums 6.1.1 Verfeinerung 1: Erweiterung des syntaktischen Baums Im ersten Schritt wird man versucht sein, den Quell-Grammatik-Baum analog zur Grammatik der Sprache Smalltalk, wie sie in der Literatur beschrieben ist, aufzubauen. Die Möglichkeiten für eine flexible Transformation und damit für eine intelligentere Übersetzung steigen jedoch, sobald man die Grammatik anreichert. Ein einfaches Beispiel: Während zum Beispiel in der Syntax von Smalltalk keine grammatikalischen Produktionen für Kontrollstrukturen (Schleifen und if- Anweisungen) vorgesehen sind, da diese durch das Versenden von Nachrichten realisiert werden, existieren sie de facto natürlich dennoch und werden aus Optimierungsgründen von den meisten Smalltalk-Compilern sowieso in spezielle Bytecodes (Anweisungen für die virtuelle Maschine) übersetzt. Erweitert man die Grammatik um diese Produktionen ist die Erzeugung der entsprechenden Java – Kontrollstrukturen einfach. 6.1.2 Verfeinerung 2: Analyse des Baums Ein traditioneller Cross-Compiler (etwa von Pascal nach C) wird versuchen den Quell-Syntax -Baum durch Parsen des Quellcodes zu bestimmen. Basiert man die Analyse des Baums aber auf den die Smalltalk-Methoden beschreibenden ByteCode, werden die in der Verfeinerung 1 angesprochenen erweiterten Produktionen einfacher bestimmbar und der Prozeß des Parsens überflüssig.

6.2 Typen-Analyse Die Analyse der Typen wird gemeinhin als der Stolperstein für eine Smalltalk- nach Java-Konvertierung betrachtet. Sie ist jedoch einfacher als erwartet, da es eine Reihe von Möglichkeiten gibt, Typen zu bestimmen. 6.2.1 Bestimmung der Typen anhand von Laufzeit-Informationen Obwohl die Typen von Smalltalk Objekten im Source-Code nicht deklariert sind, referenzieren die Variablen im Smalltalk Sourcecode zur Laufzeit konkrete Objekte, die sehr wohl einen Typ (eine Klasse) besitzen. So kann bereits bei der statischen Analyse der Instanzen von Fachklassen wie Kunde oder Adresse für einen recht hohen Prozentsatz der Attribute bestimmt werden, welchen Typ diese Attribute haben. Möglich ist diese Analyse aufgrund einer Eigenschaft von Smalltalk, die mit Reflection oder Selbstauskunft bezeichnet wird. Für eine detailliertere Analyse, mit der auch Typen von Methodenparametern oder lokalen Variablen von Methoden bestimmt werden können, werden Sendhooks installiert. Diese ermöglichen es, in Smalltalk-Systemen einen Schnappschuß des IstZustands des Laufzeitsystems nach jedem Methodenaufruf zu untersuchen. Die Methode hat jedoch den Nachteil, daß zur Analyse der Typen die Anwendung ausgeführt werden muß. 6.2.2 Protokollanalyse Es gibt eine weitere Reihe von statischen Analysen, die helfen, Typen zu bestimmen. Unter ihnen sei die Protokollanalyse vorgestellt. Diese bestimmt eindeutige Nachrichten im System und ordnet den Empfängern dieser Nachricht die implementierende Klasse zu. Ein Beispiel: Würde eine Methode detect:ifNone: nur von der Klasse Collection oder einer Unterklasse von Collection implementiert, hat ein Objekt, das diese Nachricht erhält, den Typ Collection. Aufgrund weiterer Analysen könnte diese TypInformation unter Umständen weiter eingeschränkt werden. 6.3 Transformation der Baumknoten Die Transformation des Quellbaums auf den Zielbaum ist der komplexeste Teil des Übersetzungsprozesses. Da die Transformation flexibel sein muß, sollten die transformierenden Regeln in einer Art und Weise erfaßt werden, die es dem Entwickler ermöglicht, neue Regeln einfach, verständlich und in übersichtlicher Form hinzuzufügen. Folgende Beispiele machen deutlich, welche Transformationsmöglichkeiten von entsprechenden Regeln erwartet werden. 6.3.1 Abbildung von Methodennamen Mit dem Fachterminus Setter und Getter bezeichnet man die Namen von Methoden, die Attribute von Objekten abfragen, bzw. festlegen. Im gängigen Smalltalk-StyleGuide werden diese Methoden genauso wie das Attribut genannt, wobei setzende Methoden einen Parameter habe und mit einem Doppelpunkt abgeschlossen werden. Im Java-Style-Guide werden diese Methoden mit setAttributName bzw.

getAttributName benannt. Folgendes Beispiel zeigt einen mit einer korrespondierenden Regel übersetzen Quellcode:
anEmployee name: ‘Meyer‘. anEmpoyee age: 45.

wird zu:
anEmployee.setName(“Meyer“); anEmployee.setAge(45);

6.3.2 Abbildung von Blöcken Die Enumeration über Collections allgemein ist ein in Smalltalk häufig verwendetes syntaktisches Element. Zum Beispiel kann über Dictionaries enumeriert werden, wobei für jeden Schritt ein sogenannter Block ausgeführt wird. In Java muß diese Enumeration in eine Schleife umgesetzt werden.
aDict associationsDo: [ :tempAssociation | Transcript show: tempAssociation. ].

wird zu:
Iterator tempIterator := aDict.entries().iterator(); while(tempIterator.hasNext()) { Map.Entry tempAssociation := tempIterator.next(); System.out.println(tempAssociation); }

Obwohl das Übersetzungs-Resultat im Source-Code der Quelle sehr ähnlich ist, sind die beiden Syntax-Bäume von Quelle und Ziel recht unterschiedlich. Folgende Gegenüberstellung zeigt sie in vereinfachter Form: Smalltalk-Version:
message_expression: identifier, message_selector, argument

block: block_args, statement_list

Java-Version:
statements: var_declaration, iteration_statement

var_declaration: while_statement: type_spec, while_token, declarator_name, expression, assign_token, statements var_initializer

6.4 Elemente eines Migrations-Werkzeugkastens Der Vollständigkeit halber soll hier erwähnt werden, daß der Sprachübersetzer nur ein Bestandteil eines umfangreichen Werkzeugkastens ist. Um die im zweiten Kapitel

ermittelten Anforderungen optimal abdecken zu können, sind weitere Werkzeuge nötig:  Entwicklungsumgebung - die eine integrierte parallele Java-Entwicklung aus dem Smalltalk-System erlaubt, so daß die erstellte Applikation optimal während der Migration getestet werden kann. Projektverwaltung – die konvertierte Klassen und Quellklassen parallel verwaltet und den Projektfortschritt kontrolliert. Versionsmanagement – die Integration eines Werkzeuges für die Versionskontrolle erlaubt den Abgleich von nach der Migration geänderten Quellklassen.

 

7 Fazit
Langfristig scheinen sich Smalltalk-Entwicklungswerkzeuge, insbesondere die spezifischen Varianten einzelner Hersteller, nicht als unternehmensweite Plattform mehr halten zu können. Maximal einzelne Applikationen werden basierend auf diesen Plattformen im Wartungsmodus auslaufen. Sollte aufbauend auf diesen Werkzeugen bereits große Business-Frameworks mit vielen Fach- und Vorgangsklassen, die bereits ein breites Spektrum des Unternehmens-Geschäftsmodells abdecken, entstanden sein, ist es notwendig dieses Framework in Java alternativ neu zu implementieren oder Werkzeug-gestützt zu migrieren. Der Einsatz eines Werkzeugs wird dabei immer sinnvoll sein, wenn die Größenordnung des Projekts den durch das Werkzeug verursachten Overhead gerechtfertigt. Obwohl Einflußfaktoren unterschiedlichster Art die Effizienz eines Werkzeugeinsatzes beeinflussen, spart ein Werkzeug schon bei mittleren Projektgrößen Kosten.

8 Literatur
Badeaux 97 Java Code Conventions from Netscape, Christie Badeaux, http://developer.netscape.com/library/technote/java/codestyle.html, 1997 Beck 96 Bothner 96 Fussell 97 Fussell 98 Lea Kent Beck, Smalltalk Best Practice Patterns, Volume 1: Coding Translating Smalltalk to Java, Per Bothner, http://www.cygnus.com/~bothner/smalltalk.html, 1997 SmallJava, Mark Fussell, http://www.chimu.com/publications/smallJava/index.html Java Development Standards, Mark L. Fussell, http://www.chimu.com/publications/javaStandards, 1998 Doug Lea, „Java Coding Standards“, http://gee.cs.oswego.edu/dl/html/javaCodingStd.html

Skublics + KT 96 Suzanne Skublics, Edward K. Klimas, David A. Thomas, Smalltalk with Style, Prentice Hall, Upper Saddle River, NJ, 1996 Sun 97 Java Code Conventions from Sun http://java.sun.com/docs/codeconv/html/CodeConventionsTOC.doc.html

Autor: Dipl.-Ing. Tom Krauß GEBIT, Gesellschaft für EDV-Beratung und Informatik-Technologien mbH Cicerostraße 37 10709 Berlin Tel.: 030-89 666 300, Fax 030-89 333 336 e-mail: tok@gebit.de


								
To top